[libvirt] libvirtd and LVM snapshots
I'm working on an existing system that creates, manages, and destroys Xen guests on a pool of host systems, and I use LVM copy-on-write snapshots to keep creation rapid. http://libvirt.org/storage.html describes logical volume pools, for which you simply supply the name of a volume group and it allocates volumes from that. By my reading, it appears one can even provide a list of block devices and they will be carved into extents and pooled into a VG for you. Is there any interface to libvirtd that allows it to create volumes that are snapshots of existing volumes? If not, does anyone have advice for doing so manually in a way that plays smoothly with libvirt? -- Support your droogs! Nick Moffitt nick@zork.net
On Mon, Feb 09, 2009 at 10:03:19PM +0000, Nick Moffitt wrote:
I'm working on an existing system that creates, manages, and destroys Xen guests on a pool of host systems, and I use LVM copy-on-write snapshots to keep creation rapid.
http://libvirt.org/storage.html describes logical volume pools, for which you simply supply the name of a volume group and it allocates volumes from that. By my reading, it appears one can even provide a list of block devices and they will be carved into extents and pooled into a VG for you.
Is there any interface to libvirtd that allows it to create volumes that are snapshots of existing volumes? If not, does anyone have advice for doing so manually in a way that plays smoothly with libvirt?
This was recently added in the 0.6.0 release of libvirt. Basically when creating a storage volume, you just need to pass information about the backing storage volume. It'll thus create a volume which is a snapshot of this backing store. http://libvirt.org/formatstorage.html#StorageVolBacking This is currently support for Cow, QCow, QCow2, VMDK and LVM storage types. Some of these allow for the underling backing store to be writable, others require that its readonly. At time of creation you only need to include the following in the volume XML <backingStore> <path>/var/lib/virt/images/master.img</path> <format>qcow2</format> </backingStore> Or <backingStore> <path>/dev/VolGroup00/MasterVol</path> </backingStore> Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange:
http://libvirt.org/formatstorage.html#StorageVolBacking
This is currently support for Cow, QCow, QCow2, VMDK and LVM storage types. Some of these allow for the underling backing store to be writable, others require that its readonly.
I tried the following under libvirt 0.6.0: vol = pool.createXML("""<volume type="block"> <name>hurgle</name> <capacity>2147483648</capacity> <backingStore> <path>/dev/VMs/test-disk</path> <format>raw</format> </backingStore> </volume>""", 0) It promptly created a volume, but not as a copy-on-write snapshot: "dmsetup ls --target snapshot" shows nothing, and the image has none of the data from the test-disk volume. The pool I used to create these volumes is clearly LVM: virsh # pool-dumpxml VMs <pool type='logical'> <name>VMs</name> <uuid>bde8f8ed-7e65-8323-ea93-51223d86fedd</uuid> <capacity>66433581056</capacity> <allocation>2281701376</allocation> <available>64151879680</available> <source> <name>VMs</name> <format type='lvm2'/> </source> <target> <path>/dev/VMs</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> You mentioned some constraints about permissions earlier, but I would have expected that to raise an exception--vol is a valid volume object and I can query it and mkfs it and so forth. The test-disk volume is completely quiescent and unmounted. Do I need to prepare it in some other way to make it suitable for livirt to use as the base of a snapshot? (Just for sanity's sake, I verified that libvirt.getVersion() returns 6000) -- "Forget the damned motor car Nick Moffitt and build cities for lovers and friends." nick@zork.net -- Lewis Mumford
Further sanity checking: # lvcreate --size 2G --snapshot --name lol /dev/VMs/test-disk # dmsetup ls --target snapshot VMs-lol (254, 2) -- Though the great song return no more Nick Moffitt There's keen delight in what we have: nick@zork.net The rattle of pebbles on the shore Under the receding wave. -- W. B. Yeats
Apologies for the noise: This trouble was entirely PEBCAK. -- "Man, if everything were object-oriented then rsync Nick Moffitt could do this already. Of course, if everything were nick@zork.net object-oriented I'd have a bushy moustache and be wearing flares, which would suck." -- Sean Neakums
Alas, I am now faced with a more revealing error: http://dpaste.com/hold/119347/ Looking through storage_conf.c and storage_backend_logical.c, I believe that my XML matches the XPath used on line 1005 of storage_conf.c: char *format = virXPathString(conn, "string(/volume/backingStore/format/@type)", ctxt); -- Though the great song return no more Nick Moffitt There's keen delight in what we have: nick@zork.net The rattle of pebbles on the shore Under the receding wave. -- W. B. Yeats
Nick Moffitt wrote:
Alas, I am now faced with a more revealing error:
http://dpaste.com/hold/119347/
Looking through storage_conf.c and storage_backend_logical.c, I believe that my XML matches the XPath used on line 1005 of storage_conf.c:
char *format = virXPathString(conn, "string(/volume/backingStore/format/@type)", ctxt);
I'll be posting a patch shortly which should fix this issue. Thanks, Cole
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Nick Moffitt