qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Live VM backup


From: Vincenzo Romano
Subject: Re: [Qemu-discuss] Live VM backup
Date: Wed, 30 Aug 2017 12:31:53 +0200

2017-08-30 12:27 GMT+02:00 Fam Zheng <address@hidden>:
> On Wed, 08/30 12:07, Vincenzo Romano wrote:
>> 2017-08-30 11:58 GMT+02:00 Fam Zheng <address@hidden>:
>> > On Wed, 08/30 11:45, Vincenzo Romano wrote:
>> >> 2017-08-30 11:40 GMT+02:00 Fam Zheng <address@hidden>:
>> >> > On Wed, 08/30 11:16, Vincenzo Romano wrote:
>> >> >> 2017-08-30 10:53 GMT+02:00 Fam Zheng <address@hidden>:
>> >> >> > On Wed, 08/30 08:17, Vincenzo Romano wrote:
>> >> >> >> Il 30 ago 2017 05:19, "Fam Zheng" <address@hidden> ha scritto:
>> >> >> >>
>> >> >> >> On Tue, 08/29 18:32, Vincenzo Romano wrote:
>> >> >> >> > I'd like to move away from "another virtualization solution" to 
>> >> >> >> > QEmu.
>> >> >> >> > I've more or less all the needed bits in my hands in order to 
>> >> >> >> > define,
>> >> >> >> > run and manage QEmu VMs.
>> >> >> >> > What I am missing is the knowledge of how to backup a live VM.
>> >> >> >> > Of course, if I shutdown the VM, I can simply copy its files and 
>> >> >> >> > the
>> >> >> >> > startup script on another QEmu host.
>> >> >> >> > But my main objective is to do the backup while the VM is running.
>> >> >> >> > I think I could use the snapshot feature, but have no idea on how 
>> >> >> >> > to
>> >> >> >> proceed.
>> >> >> >> > Any hint?
>> >> >> >>
>> >> >> >> In short, just do what libvirt would do: use QMP and send 
>> >> >> >> 'drive-backup'
>> >> >> >> command.
>> >> >> >>
>> >> >> >> This is a very good howto:
>> >> >> >>
>> >> >> >> https://github.com/qemu/qemu/blob/master/docs/interop/live-b
>> >> >> >> lock-operations.rst
>> >> >> >>
>> >> >> >> Fam
>> >> >> >>
>> >> >> >>
>> >> >> >> Thanks.
>> >> >> >> I presume there's a 'drive-restore', though I need to look better 
>> >> >> >> in the
>> >> >> >> docs.
>> >> >> >>
>> >> >> >> Is there any side effect in case the CPU where the VM will be 
>> >> >> >> restored is
>> >> >> >> not exactly the same as the one where the VM got backed up?
>> >> >> >
>> >> >> > No, there isn't a 'drive-restore'. 'drive-backup' only takes care of 
>> >> >> > the disks,
>> >> >> > so the CPU, ram and device states aren't saved.
>> >> >> >
>> >> >> > If you boot from the backup image, CPU and ram are restarted from 
>> >> >> > powered off
>> >> >> > state, so what happens is effectively like a power loss at the point 
>> >> >> > of
>> >> >> > 'drive-backup': anything not saved to disk are lost.
>> >> >> >
>> >> >> > Fam
>> >> >>
>> >> >> I understand.
>> >> >>
>> >> >> So, if I haven't miunderstood, at the moment QEmu-KVM doesn't
>> >> >> implement  "VM snapshots".
>> >> >
>> >> > It does. There are "savevm" and "migrate" (or "migrate -b") that can 
>> >> > save the
>> >> > CPU/ram etc:
>> >> >
>> >> > https://www.linux-kvm.org/page/Migration#savevm.2Floadvm_to_an_external_state_file_.28using_pseudo-migration.29
>> >> >
>> >> > Fam
>> >>
>> >> Thanks again, Fam.
>> >>
>> >> So I should issue both QMP commands, in theory, with the VM in a
>> >> frozen state. Right?
>> >
>> > I think with "savevm", your VM is automatically paused when the command is 
>> > being
>> > handled. The "migrate -b 'exec: ...'" way is an alternative and doesn't 
>> > need the
>> > VM to stop, which should be better.
>> >
>> > Fam
>>
>> Thanks.
>> What if the two hosts have "slightly different" CPU capabilities?
>> I have a main host with a  "Xeon E5-2620 v3" while the backup one is a
>> "Xeon E5-2407".
>> Apart of the performances, the former is lacking some instruction set
>> extensions:
>> SSE2, MMX, SSE3, SSE, SSE4.1, SSE4.2, Supplemental SSE3 and AES
>> despite being much newer than the latter which "only" lacks AVX 2.0.
>
> You can control CPU flags from the command line, and for the same reason, the
> machine types and PCI addrs, etc.
>
>>
>> In this case the current virtualization technology is showing its 
>> deficiencies.
>> For a number of reasons I am also testing this type of "corner cases",
>> when a backup cannot be restored on exactly the same hardware it comes
>> from.
>
> At this point you are already reinventing libvirt, so the answer is either use
> it or at least dig into how it manages QEMU :). It would be useful to inspect
> the QEMU command line it generates and the QMP commands it issues for certain
> management tasks, such as backup, hotplug and migration, etc.
>
> Fam

I am not willing to reinvent anything.
I am willing to understand: using a helper tool like libvirt without
understanding what's actually happening "there below" makes little
sense to me.
Thanks again for the help.

Enzo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]