Bug 1374793

(In reply to David Jaša from comment #0)
> Description of problem:
> Please allow migration within the same session. There are two use cases:
>   * after critical qemu security fixes, enable rapid move of VMs to updated
> qemu
>   * migration testing: easy to setup and more likely to hit race conditions
> IMO first one is good enough to implement the RFE and RHEV Virt team is in
> favour of the idea once libvirt supports it.
> 
> Migration works just ok when done on plain qemu so the support should be
> trivial. 

Nope, it is not at all trivial. When managing QEMU processes there are many resources libvirt sets up on the host which are tied to the VM, typically based on its name, and/or a combination of name + uuid. You can't have two copies of the same VM running on the same host without getting clashes in these resources and making libvirt support multiple different naming schemes for the same VM would have a ripple effect across the codebase and result in bugs which only ever appear when doing local-host migrations.

Domain ID seems like a good distinguishing mark for domains with the same name/uuid for file names. Good handling of qemu logging looks more difficult to me but that's not exactly good in current libvirt either (e.g. too verbose logging preventing domain startup, lack of timestamps etc).

As Daniel said, implementing generic localhost migrations would be nontrivial and don't think it's worth doing. Setting up two hosts for migration testing is not any harder than setting up a single host esp. when both can be virtual.

However, moving a running domain from an older QEMU binary to a new one (e.g., to address a security issue) is a valid scenario that is worth thinking over. Libvirtd could do it within a single API and it could even be theoretically possible to implement some optimizations in cooperation with QEMU.

That said, I'm changing the bug summary to match the first use case.

(In reply to Jiri Denemark from comment #3)
> As Daniel said, implementing generic localhost migrations would be
> nontrivial and don't think it's worth doing. Setting up two hosts for
> migration testing is not any harder than setting up a single host esp. when
> both can be virtual.
> 
> However, moving a running domain from an older QEMU binary to a new one
> (e.g., to address a security issue) is a valid scenario that is worth
> thinking over. Libvirtd could do it within a single API and it could even be
> theoretically possible to implement some optimizations in cooperation with
> QEMU.
> 
> That said, I'm changing the bug summary to match the first use case.

I don't think that "upgrading" a running QEMU in-place is any easier than supporting localhost migration - all the same problems apply wrt resources on disk clashing. 

I question whether there is a genuine value in in-place upgrade of QEMU from a security POV too. There's a reasonable number of security bugs in pieces outside QEMU that effectively necessitate migrating the guest to a separate host. So given that you need that procedure for dealing with security errata in general, I'm sceptical that it is beneficial to special case QEMU security bugs. It is better to have a consistent process applied in all cases, as that reduces the testing matrix and thus scope for failure.