4:03 p.m.
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(a)zork.net
4:05 a.m.
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 :|
7:51 a.m.
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(a)zork.net
-- Lewis Mumford
8:16 a.m.
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(a)zork.net
The rattle of pebbles on the shore
Under the receding wave. -- W. B. Yeats
9:05 a.m.
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(a)zork.net
object-oriented I'd have a bushy moustache and be
wearing flares, which would suck." -- Sean Neakums
9:21 a.m.
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(a)zork.net
The rattle of pebbles on the shore
Under the receding wave. -- W. B. Yeats
1:37 p.m.
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
5762
days inactive
5765
days old
6 comments
3 participants
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Nick Moffitt