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(a)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.
>>>> All feedback is welcome!
>> (I prefer to inline the document when discussing it)
>>> VDSM changes
>>> Default parameter will be added to vmSnapshot verb that maps string to
>>> The map will include two keys for now:
>>> 'mode' that can be mapped to 'disks_only' or
>>> indicate if memory state should be saved.
>>> 'memVol' that will be mapped to a string that represent the
>>> 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'
>>> 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
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.