[Engine-devel] [vdsm] Snapshots with RAM feature

[Michal Skrivanek]

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 at redhat.com> 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

Thanks,
michal
> 
> Dan.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel