From: "Arik Hadas" <ahadas(a)redhat.com&gt; To: engine-devel(a)ovirt.org, vdsm-devel(a)lists.fedorahosted.org Sent: Tuesday, April 9, 2013 11:01:36 AM Subject: [vdsm] Snapshots with RAM feature Hi All, The proposed feature will make it possible to run a VM which was reverted to live snapshot or created from live snapshot with the same memory state as it was at the moment the live snapshot was taken. http://www.ovirt.org/Features/RAM_Snapshots All feedback is welcome!

Regards, Arik _______________________________________________ vdsm-devel mailing list vdsm-devel(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

On 9 Apr 2013, at 10:01, Arik Hadas <ahadas(a)redhat.com&gt; wrote: > Hi All, > > The proposed feature will make it possible to run a VM which was reverted to live snapshot > or created from live snapshot with the same memory state as it was at the moment the live > snapshot was taken. > > http://www.ovirt.org/Features/RAM_Snapshots > > All feedback is welcome! Nice!

VDSM changes Default parameter will be added to vmSnapshot verb that maps string to string. The map will include two keys for now: 'mode' that can be mapped to 'disks_only' or 'disks_memory' to indicate if memory state should be saved. 'memVol' that will be mapped to a string that represent the two volums that will be used to save the memory state and the VM configuration. The default map will include the mapping of 'mode':'disks_only' only. If the 'mode' value in the map decribed above is 'disks_memory' the first volume in 'memVol' will be passed to libvirt in order to dump the memory to it, and the second volume in 'memVol' will be used to save the VM configuration (the same way it is done for hibernate operation).

On Wed, Apr 10, 2013 at 02:12:20AM -0400, Michal Skrivanek wrote: > > > On 9 Apr 2013, at 10:01, Arik Hadas <ahadas(a)redhat.com&gt; wrote: > > > Hi All, > > > > The proposed feature will make it possible to run a VM which was reverted to live snapshot > > or created from live snapshot with the same memory state as it was at the moment the live > > snapshot was taken. > > > > http://www.ovirt.org/Features/RAM_Snapshots > > > > All feedback is welcome! > Nice! (I prefer to inline the document when discussing it) > VDSM changes > > Default parameter will be added to vmSnapshot verb that maps string to string. > The map will include two keys for now: > 'mode' that can be mapped to 'disks_only' or 'disks_memory' to > indicate if memory state should be saved. > 'memVol' that will be mapped to a string that represent the two > volums that will be used to save the memory state and the > VM configuration. The default map will include the > mapping of 'mode':'disks_only' only. > > If the 'mode' value in the map decribed above is > 'disks_memory' the first volume in 'memVol' will be > passed to libvirt in order to dump the memory to > it, and the second volume in 'memVol' will be used > to save the VM configuration (the same way it is > done for hibernate operation). This definition of 'memVol' would not allow saving the state to another storage domain, or a direct lun or whatever. I suggest that you have two independet arguments, say memVol and vmConfVol. Both may have the standard pool-domain-image-volume quartet, or a lun specification, or a local path.

On 11 Apr 2013, at 14:01, Dan Kenigsberg wrote: > On Wed, Apr 10, 2013 at 11:43:12AM +0300, Dan Kenigsberg wrote: >> On Wed, Apr 10, 2013 at 02:12:20AM -0400, Michal Skrivanek wrote: >>> >>> >>> On 9 Apr 2013, at 10:01, Arik Hadas <ahadas(a)redhat.com&gt; wrote: >>> >>>> Hi All, >>>> >>>> The proposed feature will make it possible to run a VM which was reverted to live snapshot >>>> or created from live snapshot with the same memory state as it was at the moment the live >>>> snapshot was taken. >>>> >>>> http://www.ovirt.org/Features/RAM_Snapshots >>>> >>>> All feedback is welcome! >>> Nice! >> >> (I prefer to inline the document when discussing it) >> >>> VDSM changes >>> >>> Default parameter will be added to vmSnapshot verb that maps string to string. >>> The map will include two keys for now: >>> 'mode' that can be mapped to 'disks_only' or 'disks_memory' to >>> indicate if memory state should be saved. >>> 'memVol' that will be mapped to a string that represent the two >>> volums that will be used to save the memory state and the >>> VM configuration. The default map will include the >>> mapping of 'mode':'disks_only' only. >>> >>> If the 'mode' value in the map decribed above is >>> 'disks_memory' the first volume in 'memVol' will be >>> passed to libvirt in order to dump the memory to >>> it, and the second volume in 'memVol' will be used >>> to save the VM configuration (the same way it is >>> done for hibernate operation). >> >> This definition of 'memVol' would not allow saving the state to another >> storage domain, or a direct lun or whatever. >> >> I suggest that you have two independet arguments, say memVol and >> vmConfVol. Both may have the standard pool-domain-image-volume quartet, >> or a lun specification, or a local path. > > On a second thought - why should we even store vmConf on vmConfVol? Why > not keep it in Engine's db? you trust the engine db? I don't:-) RAM snapshot absolutely needs to correspond to the actual VM configuration otherwise it can crash the VM or corrupt > Sure, we do this for hibernation. But it creates a lot of inconsistency pains. > Engine sends one vmconf to vdsm, but vdsm ignores it and starts the VM > with an old vmconf that was stored besides the hibernation volume. On > top of this, it wastes some GiB of disk space for each snapshot. Pardon my lack of knowledge in this area, how/where is it wasting that much?

> I think it is time to have Engine keep a snapshot of its vm config > whenever it takes a snapshot - live or offline. I'm really not sure about the impacts when it goes out of sync. I'd rather have the VM resumed and configuration in engine updated/overwritten afterwards in first stats update than screwing up the VM