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

[Dan Kenigsberg]

On Fri, Apr 19, 2013 at 10:30:19AM +0200, Michal Skrivanek wrote:
> 
> 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?

If I recall correctly, Engine has a 1GiB minimum for the size of the LV
that it can create, for one odd reason or another. vmConf takes less
than 1% of that.

> 
> > 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

I do not know why you trust the Engine DB less than the content of an
LV. Sure, keeping a copy of vmConf near the RAM snapshot, may be useful
in case of a total DB crash, or a manual vm-export. But it duplicates
data, and the fact that it may be possible to do it this way, is not a
good reason to avoid making Engine aware of that vmConf is a snapshot
property, not a vm property.

It is a shame that we cannot add/remove a disk/nic/video card to a VM
without affecting history retroactively.

Dan.