[libvirt] qemu: managedsave vs. save

Laine Stump laine at laine.org
Fri May 2 13:43:55 UTC 2014


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).

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).

(BTW, both virsh save and virsh managedsave are implemented by telling
qemu to "migrate to disk", so in the end it's all the same thing; all
that changes is the level of details that libvirt manages for you)




More information about the libvir-list mailing list