[libvirt] qemu: managedsave vs. save

[Richard Weinberger]

On Fri, May 2, 2014 at 4:36 PM, Laine Stump <laine at laine.org> wrote:
> On 05/02/2014 04:52 PM, Richard Weinberger wrote:
>> On Fri, May 2, 2014 at 3:43 PM, Laine Stump <laine at laine.org> wrote:
>>> On 05/02/2014 03:38 PM, Richard Weinberger wrote:
>>>> On Fri, May 2, 2014 at 2:16 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>>>>> On Fri, May 02, 2014 at 02:08:28PM +0200, Richard Weinberger wrote:
>>>>>> Hi!
>>>>>>
>>>>>> My KVM hosts share the same filesystem and I'm facing an issue using
>>>>>> managedsave.
>>>>>> If I save vmX using managedsave on hostA and restore it later using
>>>>>> "virsh restore" in hostB
>>>>>> the qemu process consumes 100% CPU and makes no progress.
>>>>>> On the other hand, if I save vmX using save the restore works fine on hostB.
>>>>> FWIW, you use 'managedsave' then you shouldn't use 'restore' - you
>>>>> should just 'start' the guest as normal and libvirt will automagically
>>>>> use the managed save image.
>>>>>
>>>>> Of course this doesn't explain the problem you see - the result of
>>>>> managedsave should be identical to the result of save. They use the
>>>>> same QEMU code internally, the only difference being that in one
>>>>> case you decide the filename and in the other case libvirt decides
>>>>> the filename
>>>> BTW: On a different system with libvirtd 1.2.3 restore works fine
>>>> from managedsave'd domains.
>>>>
>>>> Looks like I have to upgrade my libvirt. :-\
>>> But you still should not use a combination of managedsave + [manually
>>> moving the config & save file to other system] + restore to migrate a
>>> guest from one host to another. This is misuse of managedsave, and extra
>>> work that you shouldn't have to do. (managedsave is really intended to
>>> be used to temporarily pause a guest so that, e.g., the host can be
>>> rebooted, after which the guest can be restarted *on the same host* by
>>> using virsh start; this is used by the libvirt-guests service. Although
>>> starting this saved image on a different host may currently work, there
>>> is no guarantee that it will continue to work in the future).
>> Then please clearly state this in the man page and create .save images
>> which is unable to be resumed by "restore" to prevent further misuse. :)
>>
>>> Instead look into the virsh migrate command. It will do all the dirty
>>> work for you, including removing the guest definition from the source
>>> host and defining it on the destination host if you want, and it
>>> minimizes guest downtime to "something very short". It can also migrate
>>> the storage if you need it to (although this increases the migration
>>> time considerably).
>> I cannot use migrate because I'm using DRBD.
>> Takeover from hostA to hostB works as follows:
>> 1. save all VMs do disk
>> 2. unmount the fs on hostA
>> 3. make hostA secondary in the DBRD cluster
>> 4. make hostB primary
>> 5. mount the fs on hostB
>> 6. restore saved VMs on hostB
>
> Ah, so the two machines are not simultaneously available. That changes a
> lot.

They are simultaneously available, but only one can access the filesystem
by the nature of DRBD.

>> Looks like I have to update /etc/init.d/libvirt-guests to use a plain "save"
>> instead of "managedsave".
>
> Well, as Daniel said earlier, there is no difference in produced file
> between save and managedsave, and I don't know that either of these is
> explicitly documented as creating a saved image that can be restarted on
> a different machine. This is what led to my comment about misusing
> managedsave. But your case sounds like a "legitimate misuse" :-) (since
> migration requires that both machines be available at the same time).
>
> So lacking a more formally approved method, there shouldn't be any
> problem with what you are doing, but keep in mind that if there is any
> difference between the software/hardware of the two machines that could
> prevent the saved image from being properly restored on the new host,
> you'll need to take care of the fallout of that yourself (if you were
> able to use migration, the migration would fail and leave you with the
> guest still running on the original host).

Both hosts are identical by design.

> (I wonder if we should officially state that the saved image can be
> safely restored on a different machine as long as it is "similar"
> (whatever that means) so that people in this situation can safely do as
> you're doing without fear of breakage after some hypothetical future
> change. Or maybe we *do* say that somewhere and I've just never seen it...)

BTW: managedsave && restore fails also on the same host.
Only save && restore works fine.

-- 
Thanks,
//richard