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 <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?
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. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel