[one-users] KVM snapshots
Ruben S. Montero
rsmontero at opennebula.org
Fri Aug 23 15:50:07 PDT 2013
Hi
You may try the solution from the libvirt community. Add a volatile disk of
type qcow2 to the VM template, it will be created in the system ds and will
give you the qcow volume to store the VM state....
Cheers
On Sat, Aug 24, 2013 at 12:48 AM, Ruben S. Montero <rubensm at dacya.ucm.es>wrote:
> Hi
>
> You may try the solution from the libvirt community. Add a volatile disk
> of type qcow2 to the VM template, it will be created in the system ds and
> will give you the qcow volume to store the VM state....
>
> Cheers
>
> Ruben
>
>
> On Thu, Aug 22, 2013 at 8:55 AM, Tobias Brunner <tobias at tobru.ch> wrote:
>
>> Hi,
>>
>>
>> Well, can you do it manually on the same configuration? It should be
>>> easy to verify.
>>>
>>
>> I've tried to do it manually:
>>
>> # virsh snapshot-create one-5
>>
>> error: unsupported configuration: internal checkpoints require at least
>> one disk to be selected for snapshot
>>
>> Asking the libvirt ML leads to this answer:
>>
>> An internal snapshot of a VM requires that the VM has at least one disk
>>> using a QCOW2 volume or similar. The memory state is saved in that
>>> image. Your VM has only a RAW disk image and thus it can't be used for
>>> internal snapshot.
>>>
>>> You can either use an external snapshot (the memory image is stored
>>> separately), but the support for external snapshots isn't finished yet
>>> (they can't be reverted automatically).
>>>
>>> The second option is to convert your VM to a qcow2 image file..
>>>
>>
>> And later:
>>
>> How can I create an external snapshot?
>>>>
>>> Add '--disk-only' for an offline domain, or use 'virsh
>>> snapshot-create-as --memspec' instead of 'snapshot-create' for an online
>>> guest (you can also use snapshot-create for an external snapshot, but
>>> you have to write appropriate XML for the case, rather than relying on
>>> the no-arg option that provides a default XML for an internal snapshot;
>>> so I find snapshot-create-as a lot easier to work with).
>>>
>>> Internal snapshots require qcow2 (or the less-used qed) file format,
>>> full stop. If you want your snapshots to live on RBD storage backend,
>>> then you either layer the qcow2 file on top of that backend, or you use
>>> external snapshots.
>>>
>>
>> Some system information:
>> * Ubuntu 13.04 64Bit
>> * virsh --version: 1.0.2
>> * OpenNebula version 4.2
>> * The XML of the VM is below
>>
>> Does anyone have snapshots running using RBD?
>>
>> Cheers,
>> Tobias
>>
>>
>> <domain type='kvm' id='4'>
>> <name>one-5</name>
>> <uuid>cff38c6a-2996-7709-c4f4-**0ed826c2fb02</uuid>
>> <memory unit='KiB'>524288</memory>
>> <currentMemory unit='KiB'>524288</**currentMemory>
>> <vcpu placement='static'>1</vcpu>
>> <cputune>
>> <shares>1024</shares>
>> </cputune>
>> <os>
>> <type arch='x86_64' machine='pc-i440fx-1.4'>hvm</**type>
>> <boot dev='hd'/>
>> </os>
>> <features>
>> <acpi/>
>> </features>
>> <clock offset='utc'/>
>> <on_poweroff>destroy</on_**poweroff>
>> <on_reboot>restart</on_reboot>
>> <on_crash>destroy</on_crash>
>> <devices>
>> <emulator>/usr/bin/kvm</**emulator>
>> <disk type='network' device='disk'>
>> <driver name='qemu' type='raw' cache='none'/>
>> <source protocol='rbd' name='one/one-5-5-0'/>
>> <target dev='hda' bus='ide'/>
>> <alias name='ide0-0-0'/>
>> <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>> </disk>
>> <disk type='file' device='cdrom'>
>> <driver name='qemu' type='raw'/>
>> <source file='/var/lib/one//**datastores/0/5/disk.1'/>
>> <target dev='hdb' bus='ide'/>
>> <readonly/>
>> <alias name='ide0-0-1'/>
>> <address type='drive' controller='0' bus='0' target='0' unit='1'/>
>> </disk>
>> <controller type='ide' index='0'>
>> <alias name='ide0'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>> function='0x1'/>
>> </controller>
>> <controller type='usb' index='0'>
>> <alias name='usb0'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
>> function='0x2'/>
>> </controller>
>> <interface type='bridge'>
>> <mac address='02:00:c0:a8:31:97'/>
>> <source bridge='vmbr0'/>
>> <virtualport type='openvswitch'>
>> <parameters interfaceid='6e492227-cd8b-**
>> f472-9f3d-1161ddf9ecfc'/>
>> </virtualport>
>> <target dev='vnet0'/>
>> <alias name='net0'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
>> function='0x0'/>
>> </interface>
>> <input type='mouse' bus='ps2'/>
>> <graphics type='vnc' port='5905' autoport='no' listen='0.0.0.0'>
>> <listen type='address' address='0.0.0.0'/>
>> </graphics>
>> <video>
>> <model type='cirrus' vram='9216' heads='1'/>
>> <alias name='video0'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x02'
>> function='0x0'/>
>> </video>
>> <memballoon model='virtio'>
>> <alias name='balloon0'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
>> function='0x0'/>
>> </memballoon>
>> </devices>
>> <seclabel type='dynamic' model='apparmor' relabel='yes'>
>> <label>libvirt-cff38c6a-2996-**7709-c4f4-0ed826c2fb02</label>
>>
>> <imagelabel>libvirt-cff38c6a-**2996-7709-c4f4-0ed826c2fb02</**imagelabel>
>> </seclabel>
>> </domain>
>>
>>
>>
>> ______________________________**_________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/**listinfo.cgi/users-opennebula.**org<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>
>>
>
>
>
> --
> Dr. Ruben Santiago Montero
> Associate Professor (Profesor Titular), Complutense University of Madrid
>
> URL: http://dsa-research.org/doku.php?id=people:ruben
> Weblog: http://blog.dsa-research.org/?author=7
>
--
--
Join us at OpenNebulaConf2013 in Berlin, 24-26 September, 2013
--
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130824/995b4ed1/attachment-0002.htm>
More information about the Users
mailing list