On Fri, May 2, 2014 at 4:36 PM, Laine Stump <laine@xxxxxxxxx> wrote: > On 05/02/2014 04:52 PM, Richard Weinberger wrote: >> On Fri, May 2, 2014 at 3:43 PM, Laine Stump <laine@xxxxxxxxx> wrote: >>> On 05/02/2014 03:38 PM, Richard Weinberger wrote: >>>> On Fri, May 2, 2014 at 2:16 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list