11:01 a.m.
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!
Regards,
Arik
11:29 a.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
----- Original Message -----
From: "Arik Hadas" <ahadas(a)redhat.com>
To: engine-devel(a)ovirt.org, vdsm-devel(a)lists.fedorahosted.org
Sent: Tuesday, April 9, 2013 11:01:36 AM
Subject: [vdsm] Snapshots with RAM feature
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!
Thanks Arik,
I beleive we will be able to levarage it with the new Backup API that we are planning for
3.3 (http://www.ovirt.org/Features/Backup-Restore_API_Integration)
Sean
Regards,
Arik
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
9:12 a.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
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.
http://www.ovirt.org/Features/RAM_Snapshots
All feedback is welcome!
Nice!
Perhaps on "Run VM" - how about instead of giving an option on start we'd
have the possibility to strip the saved ram in snapshot beforehand? And keep the run logic
as always start with ram when it exists.
Also it is important to discard the ram on all forms of Run VM. Better discard it on error
than mistakenly rerun with ram twice
Regards,
Arik
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
11:43 a.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
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.
>
> 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.
3:01 p.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
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.
> >
> > 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?
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.
I think it is time to have Engine keep a snapshot of its vm config
whenever it takes a snapshot - live or offline.
Dan.
11:30 a.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
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.
>>>
>>> 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-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:45 p.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
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.
>>>>
>>>> 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.
5:16 p.m.
New subject: [Engine-devel] [vdsm] Snapshots with RAM feature
----- Original Message -----
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.
>
> http://www.ovirt.org/Features/RAM_Snapshots
>
> All feedback is welcome!
Nice!
Perhaps on "Run VM" - how about instead of giving an option on start we'd
have the possibility to strip the saved ram in snapshot beforehand? And keep
the run logic as always start with ram when it exists.
Yes, it makes sense to keep the run vm process short and simple by using the
logic you propose and not to display any dialog in the process.
An alternative approach for the removal of the ram from the snapshot can be
to display a check box in the clone vm from snapshot dialog so that
the user will be able to select whether to take the memory from the snapshot
or not. and in the preview snapshot process to display a dialog with such
check box also. that way we will be able to create both with memory state and
without memory state VMs from snapshot that contains memory state.
Also it is important to discard the ram on all forms of Run VM.
Better
discard it on error than mistakenly rerun with ram twice
Absolutely, we should ensure that we remove the ram from the VM configuration
if there's a chance that either the disks or the memory was changed since the
VM was created from/reverted to the snapshot.
>
> Regards,
> Arik
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
12:41 p.m.
Hi All,
The feature's wiki page has been massively updated
(http://www.ovirt.org/Features/RAM_Snapshots)
Major changes:
1. Withdraw the option of using the saved memory from snapshot when creating
a VM from snapshot as the initial memory state of the VM, as it turned out that
the VM configuration is stored inside the memory file.
2. Simplified the API between the engine and VDSM: using comma-separated string
to represent the memory volume (which can be empty) instead of map with 'mode'
and pool-domain-image-volume quartet values.
Again, All feedback is welcome!
Regards,
Arik
----- Original Message -----
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!
Regards,
Arik
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4207
days inactive
4244
days old
8 comments
5 participants
participants (5)
-
Arik Hadas -
Dan Kenigsberg -
Michal Skrivanek -
Michal Skrivanek -
Sean Cohen