7:53 a.m.
On 12/19/2014 04:23 PM, Boylan, Ross wrote:
Hi. I have some narrow questions and a larger one.
[please configure your mailer to wrap long lines]
If I make an existinig LVM VG a storage pool, can I use some of the LV's for libvirt
and some for the host? Or does the VG needed to be completely dedicated to
virtualization?
It is technically possible to share VGs, but I would probably advise
against it. Why? Unless you set up udev rules or other tricks to
ensure that the host does not probe the LVs dedicated to guest storage,
you could risk accidentally mounting the LV in the host at the same time
it is passed through to the guest, and that is a potential recipe for
data corruption. It's easier to isolate resources if you can guarantee
that the storage pools being allocated to guests are distinct from the
storage pool that the host uses for itself.
Assuming mixed use is possible, is it possible to do an LVM snapshot of an LV in use for
a VM? The snapshot would have to be initiated and used on the host, I assume.
LVM snapshots are definitely possible for offline guests. Also, with
new enough libvirt, you can freeze guest I/O, take an LVM snapshot, then
resume guest I/O; although I haven't played with that much. However,
any scenario that requires changing the file name opened by qemu to
represent the latest data is not very well supported (qemu does not yet
have a way to pivot over to a new external file name that represents the
same contents as the pre-snapshot state). On the other hand, qemu is
definitely gaining some cool features like external snapshot (where the
original file becomes a read-only backing file to a temporary qcow2
file), then you do external backup of the original file, then do an
active commit back into the original, which can help in getting clean
scenarios for useful backups via LVM snapshots or other means without
risking data corruption.
How dynamic is this? If I create a new LV, is it possible to see that immediately from,
e.g., virt-manager and add it as a virtual disk to a running VM? If I resize the LV, will
the VM know so that, e.g., I could do an online resize of the filesystem?
Refreshing the pool view will see new LVs, and there are libvirt APIs
for resizing a VM (you DO have to use the libvirt API; you can't just
blindly assume that the guest will see more storage unless you have used
the right APIs).
My larger question is what the recommendations are for managing disks or LV's with
libvirt and KVM on Linux. In particular, I'd like to be able to grow storage space as
the the VM needs grow, and snapshot (in the LVM sense) some of the block devices behind
filesystems for backup. Although it would be nice to grow space while the VM's are
running, it's not a requirement.
Sounds like you are interested in reinventing what VDSM already does
(VDSM uses LVM volumes to grow storage as needed for guests across a
cluster).
Following advice on the KVM list, I have been using raw LV's as virtual disks for the
VM's. The host is currently running with a large, encrypted LVM VG. It would be
convenient to use it for the VM's.
As for whether files in the host filesystem atop its LVM, vs. separate
LVMs entirely, is more efficient, you'd have to benchmark the difference
it makes (fewer layers by using LVMs directly probably makes for more
efficiency, but it also means more effort in setting things up compared
to just using files in the same host filesystem).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org