[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Ovirt-devel] Modeling LVM storage
- From: Steve Ofsthun <sofsthun virtualiron com>
- To: Scott Seago <sseago redhat com>
- Cc: "ovirt-devel redhat com" <ovirt-devel redhat com>
- Subject: Re: [Ovirt-devel] Modeling LVM storage
- Date: Tue, 16 Sep 2008 17:05:12 -0400
Scott Seago wrote:
Some additional clarification based on a conversation I just had with
No changes from the basic model side of things, but we do want to
explicitly exclude any LVM bits in LUNs assigned directly to VMs. So if
a VM carves up one of its assigned LUNs into multiple LVs, oVirt doesn't
care -- we only show the whole LUN assigned to a VM. The other thing is
that we don't want to explicitly scan all unused LUNs for PVs/LVs --
rather we should do this on-demand.
How would this "on-demand" scanning be done?
The only way to selectively scan volumes (with pvscan) is to update /etc/lvm/lvm.conf to restrict the desired list of volumes to scan. This can be a pain to manage, particularly if the local node requires LVM access to boot. If a newly scanned LUN contains volume information that conflicts with an existing volume group (say VolGroup00), the pvscan will error out due to conflicting volume group information (not so bad). More importantly though, if the system is rebooted at this point, the reboot will fail to activate the real VolGroup00 possibly compromising the entire boot process (not so good). Even if a boot volume isn't compromised, some active volume group is no longer accessible.
A safer alternative would be to modify pvscan to allow selective volume scanning without changing /etc/lvm/lvm.conf. Is this a possible alternative? Would a modified pvscan be acceptable in upstream lvm?
Another alternative, as Daniel mentioned, is to not allow a guest direct access to the entire LUN.
If we think of it in terms of the "new VM" ui. There are several types
of storage available, but selecting storage will basically be a two-step
process. Initially the user will be presented with a list of NFS storage
pools (i.e. NFS mounts), and iSCSI storage volumes (i.e. LUNs). If an
NFS pool is chosen, the user can pick an existing unallocated NFS
Storage Volume (image file) or create a new NFS Volume/image file with a
specified size (within the user's quota) to be 1) added to the NFS pool;
and 2) attached to the VM.
If an iSCSI volume (LUN) is chosen, there are a couple of options. First
of all, the LUN will be scanned for PVs/LVs. These PVs/LVs will be
inserted into the oVirt DB as LVM storage pools/volumes. The user will
be able to choose an existing LV, create a new LV, or choose the whole
LUN to attach to the VM. The latter "whole LUN" option only exists if
there are not any LVs currently attached to other VMs. When a whole LUN
is attached to a VM, the individual PVs/LVs are removed from the ovirt
DB, since they can be overwritten at any time by the VM anyway.
The other aspect of this is what is seen on the Hardware Pool/Storage
tab. Right now we see NFS/iSCSI pools in the top-level list, and
NFS/iSSCSI storage volumes when we drill down. For NFS, we need to allow
creation/deletion of NFS Volumes (image files). For iSCSI, we need to
allow the user to drill down from iSCSI Volumes (LUNs) to LVM Pools and
Volumes (VGs and LVs). Two things here we need to work out:
1) drilling down will require refreshing the LVM Pool, as we only scan
these on demand -- at any given time, oVirt will not have a complete
picture of all LVM Pools for every LUN in the db
2) The UI is already fairly crowded with the Target -> LUN drilldown --
now we're adding another level. I'm guessing that at the moment, the
best way to show this will be via another facebox popup, but we still
need to work through the UI implications.
Perry -- does this cover most of what we discussed?
Chris Lalancette wrote:
sseago and I (and variously, other folks) had a somewhat longish
IRC today about carving up storage with LVM. This is the second time
beaten this horse, so hopefully we are somewhat OK now. The basic
idea is that,
given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to
1) Assign the entire LUN to a guest (this is the way that ovirt works
2) Carve up the LUN using LVM, and then hand out individual logical
Libvirt handles this case sort of implicitly; that is, you first build
pool for iscsi, and find all of the volumes on it. Then you build an LVM
storage pool out of the iSCSI LUN, and then you can create volumes on
top of that.
We can follow the same sort of model for ovirt. That is, we currently
StoragePool defined in the model, which contains 0 or more
the idea is that we now add a new type of StoragePool, LVM, which
one or more iSCSI StorageVolumes, and on top of that, you have a new
StorageVolume, LVM, which is what you eventually assign to guests.
Note that the above model should eventually support binding multiple
into a single LVMPool, although we won't expose that functionality to
for the moment.
Once those model changes are in place, then we just need the backend
code to handle this (I've worked on that somewhat today, so I have a
handle on what it will require), and the frontend WUI pieces. This
get somewhat complex, so for the time being, we will have pretty
support. That is, during VM creation time, we'll allow a user to
an existing whole LUN for the guest, choose an already existing (but
not in use)
LVM volume for the guest, or carve out a new LVM volume for the guest
to physical disk space and user quota, naturally). Later on we'll add
complicated handling of LVM, such as deletion, resizing, etc. etc.
Ovirt-devel mailing list
Ovirt-devel redhat com
[Date Prev][Date Next] [Thread Prev][Thread Next]