Difference between revisions of "Libvirt external snapshot with GlusterFS"
From stoney cloud
[unchecked revision] | [unchecked revision] |
(Created page with "With recent versions of Libvirt and Qemu it is possible to create external disk snapshots while the current and future volumes are connected natively to the GlusterFS cluster ...") |
(→Part 3: Check the disks) |
||
Line 40: | Line 40: | ||
</pre> | </pre> | ||
− | === Part 3: Check | + | === Part 3: Check === |
+ | |||
+ | ==== Libvirt ==== | ||
+ | <pre> | ||
+ | vm-test-02 ~ # virsh snapshot-list d4572522-eae4-4e3e-ab36-618ae4a91fb4 | ||
+ | Name Creation Time State | ||
+ | ------------------------------------------------------------ | ||
+ | snap 2014-05-02 15:16:09 +0200 disk-snapshot | ||
+ | |||
+ | vm-test-02 ~ # virsh snapshot-info d4572522-eae4-4e3e-ab36-618ae4a91fb4 --current | ||
+ | Name: snap | ||
+ | Domain: d4572522-eae4-4e3e-ab36-618ae4a91fb4 | ||
+ | Current: yes | ||
+ | State: disk-snapshot | ||
+ | Location: external | ||
+ | Parent: - | ||
+ | Children: 0 | ||
+ | Descendants: 0 | ||
+ | Metadata: yes | ||
+ | |||
+ | </pre> | ||
==== VM Image Path ==== | ==== VM Image Path ==== |
Revision as of 14:39, 2 May 2014
With recent versions of Libvirt and Qemu it is possible to create external disk snapshots while the current and future volumes are connected natively to the GlusterFS cluster via gfapi (not via FUSE).
For this test, the following versions have been used:
- GlusterFS: 3.4.2
- Qemu: 1.7.0
- Libvirt: 1.2.3
Contents
Part 1: Preparation
- VM-Name
- d4572522-eae4-4e3e-ab36-618ae4a91fb4
- Original GlusterFS Image Path
- virtualization/vm-templates/5b77d2f6-061f-410c-8ee7-9e61da6f1927/de7c7c4e-8664-4ac7-b559-53fd52ec461c.qcow2
snap.xml:
<domainsnapshot> <name>snap</name> <disks> <disk name='vda' type='network'> <driver type='qcow2'/> <source protocol='gluster' name='virtualization/vm-templates/5b77d2f6-061f-410c-8ee7-9e61da6f1927/de7c7c4e-8664-4ac7-b559-53fd52ec461c.snap01.qcow2'> <host name='10.1.120.11'/> </source> </disk> </disks> </domainsnapshot>
Part 2: Create the snapshot using virsh
virsh snapshot-create d4572522-eae4-4e3e-ab36-618ae4a91fb4 snap.xml --disk-only --atomic
Ex.
vm-test-02 ~ # virsh snapshot-create d4572522-eae4-4e3e-ab36-618ae4a91fb4 snap.xml --disk-only --atomic Domain snapshot snap created from 'snap.xml'
Part 3: Check
Libvirt
vm-test-02 ~ # virsh snapshot-list d4572522-eae4-4e3e-ab36-618ae4a91fb4 Name Creation Time State ------------------------------------------------------------ snap 2014-05-02 15:16:09 +0200 disk-snapshot vm-test-02 ~ # virsh snapshot-info d4572522-eae4-4e3e-ab36-618ae4a91fb4 --current Name: snap Domain: d4572522-eae4-4e3e-ab36-618ae4a91fb4 Current: yes State: disk-snapshot Location: external Parent: - Children: 0 Descendants: 0 Metadata: yes
VM Image Path
vm-test-02 ~ # virsh dumpxml d4572522-eae4-4e3e-ab36-618ae4a91fb4 | grep "\.qcow2" <source protocol='gluster' name='virtualization/vm-templates/5b77d2f6-061f-410c-8ee7-9e61da6f1927/de7c7c4e-8664-4ac7-b559-53fd52ec461c.snap01.qcow2'>
Backing File Path
Unfortunately, the domblkinfo
command still does not understand natively attached glusterfs volumes, but qemu-img does:
vm-test-02 ~ # qemu-img info gluster://10.1.120.11/virtualization/vm-templates/5b77d2f6-061f-410c-8ee7-9e61da6f1927/de7c7c4e-8664-4ac7-b559-53fd52ec461c.snap01.qcow2 image: gluster://10.1.120.11/virtualization/vm-templates/5b77d2f6-061f-410c-8ee7-9e61da6f1927/de7c7c4e-8664-4ac7-b559-53fd52ec461c.snap01.qcow2 file format: qcow2 virtual size: 200G (214748364800 bytes) disk size: 2.6M cluster_size: 65536 backing file: gluster://10.1.120.11/virtualization/vm-templates/5b77d2f6-061f-410c-8ee7-9e61da6f1927/de7c7c4e-8664-4ac7-b559-53fd52ec461c.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false