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 Thanks, michal > > Dan. > _______________________________________________ > Engine-devel mailing list > engine-de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel