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 <aha...@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

> Dan.
> _______________________________________________
> Engine-devel mailing list
> engine-de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

vdsm-devel mailing list

Reply via email to