[ovirt-users] oVirt VM backup and restore

[Gianluca Cecchi]

On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi at gmail.com>
wrote:

>
>
> NOTE: during the snapshot creation I see in web admin console the VM in
> paused state and also not responsive in both console and ssh session.
> After a couple of seconds it comes back and as a confirmation I see this
> in its messages:
>
> Mar  8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230
> seconds, adjustment started
>
> Is this expected?
>
>
>
>
Possibly the default changed at some point in time, so that now it saves
memory and so this implies pause of VM

In the mean time I verified changing backup.py this way solves the problem
(the 3.6 api deprecation still in place... ;-):

$ diff backup.py backup.py.orig
123c123
<
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(),
vm=vm,persist_memorystate=False))
---
>
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(),
vm=vm))

The snapshot doesn't include memory and no problem at VM OS side now

Tested also getting the parameter from config file

Modifications needed in this case:

1)
$ diff backup.py backup.py.orig
123c123
<
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(),
vm=vm,persist_memorystate=config.get_persist_memorystate()))
---
>
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(),
vm=vm))


2)
$ diff config.py config.py.orig
34d33
<             self.__persist_memorystate =
config_parser.getboolean(section, "persist_memorystate")
113,116d111
<
<
<     def get_persist_memorystate(self):
<         return self.__persist_memorystate


And in config file called add:

# Save Memory in snapshot
persist_memorystate=False

It could be further improved if one wants to differentiate save memory for
some VMs and not for other ones....

HIH other ones,
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170309/d0d6b841/attachment.html>