OpenNebula

here is the addon-storpool commit that implements a solution:
https://github.com/OpenNebula/addon-storpool/commit/989f5a3c8ee340252053712b4c7c594edecf24a7

Well to proposed (second) solution is not working if there are more than one disk attached to the VM :(

Only first proposal left. Or there are other solution?

Kind Regards,
Anton Todorov

Currently, the users need to guarantee that the snapshots can be safely taken, and they need to be aware that snapshots require to sync the guest OS state. Currently the driver supports three modes for VMs in RUNNNING:

1.- interactive, the TM driver + hypervisor needs to support live snapshots. You need to be aware of possible caching and sync'ing issues

2.- suspend, the VM is suspended/resumed. You may also have sync'ing issues

3.- detach, disk is detached/attached from the VM to take the snapshot. Also you probably need to unmount it first; and it will not work for the root FS.

We are working on made cloud view more flexible, so in case that end-users are not aware of things going on behind the scenes, you may for example disable snapshots in RUNNING. Also we could force this for all VMs at the driver level...

Also, for kvm, guest agent may be used to quiesce the guest. We did not include this because it implies extra conf steps for the guest. But given it as an option could work.

BTW, I've also created a new issue for the other issues #4056. Feel free to update it.

THANKS!!

Hi Ruben,

I've delayed my response to recheck/verify the following.

I found the following interfaces regarding snapshots:

• it is calling virsh --connect $LIBVIRT_URI snapshot-create-as $DOMAIN. It is not investigated in details because our libvirt integration is not ready yet.
• is this the interactive snapshot that do you mention?

• (inconsistent) "live" snapshot via tm_mad/cpds driver
• I would classify this as the interactive snapshot too?

• (incosistent) "suspend" snapshot.

• (consistent) "poweroff" snapshot
• You do not mention this snapshot.

I could not find where/how the detach snapshot is triggerred?

All mentioned above types/methods are creating more or less consistent snapshots. In most cases the VM will boot, at least with quick fsck on the incosistent ones.

Utilizing/Reverting snapshots

• IMO there a bold red warning should be displayed so users must know/confirm what are they doing

4. "power off" snapshots are same as (3.) - ok on poweroff, probable on unmounted disks, disaster on root fs disk.

Also, for kvm, guest agent may be used to quiesce the guest. We did not include this because it implies extra conf steps for the guest. But given it as an option could work.

For me the fs freeze/thaw via the qemu guest agent is best, safe and fastest option for taking snapshots. I do not agree that there is need for too much extra conf steps for the guests. Here are my tests for most of the distributions imported from the Marketplace:

Ubuntu 14.04 LTS
root@ubuntu:~# apt-get update
root@ubuntu:~# apt-get install qemu-guest-agent

Ubuntu 15.04
root@ubuntu:~# apt-get update
root@ubuntu:~# apt-get install qemu-guest-agent

CentOS 6.5
[root@localhost ~]# yum install qemu-guest-agent
[root@localhost ~]# service qemu-ga start

CentOS 7.1
[root@localhost ~]# yum install qemu-guest-agent
[root@localhost ~]# systemctl start qemu-guest-agent

Debian 7 "Wheezy" 
root@debian:~# echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list.d/wheezy-backports.list
root@debian:~# apt-get update
root@debian:~# apt-get install qemu-guest-agent

Debian 8 "Jessie" (virtio-blk only - extlinux expects /dev/vda1)
root@debian:~# apt-get update
root@debian:~# apt-get install qemu-guest-agent

As you can see the only need is to install/enable the qemu guest agent. It is more tricky to enable the guest agent socket in libvirt on the HV hosts, especially on Debian/Ubuntu ones(apparmor). But once it is made it is working without further problems.

What do you think about a solution like this: if the VMM drivers knows the context in which they are called (via STATE/LCM_STATE?) they could test for guest agent availability and fs freeze/thaw else they should fallback to current logic.

Kind Regards,
Anton Todorov
ps. While testing i've spot some more (irrelevant) issues, I'll open separate tickets for them :)

@Anton Todorov, I created #4064 for --quiesce support for qcow2 based disk snapshots. This feature (--quiesce) has lived in a development OpenNebula version for some days but if a VM has no guest agent running ... it gave issues creating a snapshot ... and therefore this support was removed. #4064 is created to smarten the disk snapshot driver (i.e. check if VM has guest agent support) to allow for consistent snapshots.

Hi Stefan,

I've checked the --quiesce option and it looks like that it will work only on storage backends that have native libvirt support. Actually my suggestion is equivalent of --quiesce but done outside libvirt so it will work with both native and no-native supported libvirt block backends. To test is qemu-guest-agent working is simple:

virsh qemu-agent-commad <DOMAIN_ID> '{"execute":"guest-ping"}'

At least for StorPool driver if fs freeze inside VM is not working it will do snapshot wit state no worst than the current situation.

Kind Regards,
Anton Todorov

Update about my statement:

I could not find where/how the detach snapshot is triggerred?

I am so sorry that I've totally missed the snap_create_live and the new options for vmm_exec where related configuration is placed. Even Javi hinted about it few months before but I totally lost traction about it.

So the live snapshot function with enabled qemu-guest-agent is implemented in our addon via tm/snap_create_live and working like charm - the snapshots creation time is about 2 seconds.

Regards,
Anton Todorov