Re: [Qemu-devel] R: Re: [PATCH v2] target/i386: kvm: add VMX migration blocker

[Dr. David Alan Gilbert]

* Paolo Bonzini (address@hidden) wrote:
> 
> ----- Cole Robinson <address@hidden> ha scritto:
> > On 4/12/19 3:47 AM, Paolo Bonzini wrote:
> > > On 10/04/19 20:26, Cole Robinson wrote:
> > >> On 11/20/18 6:44 AM, Dr. David Alan Gilbert wrote:
> > >>> * Paolo Bonzini (address@hidden) wrote:
> > >>>> Nested VMX does not support live migration yet.  Add a blocker
> > >>>> until that is worked out.
> > >>>>
> > >>>> Nested SVM only does not support it, but unfortunately it is
> > >>>> enabled by default for -cpu host so we cannot really disable it.
> > >>>>
> > >>>> Signed-off-by: Paolo Bonzini <address@hidden>
> > >>>
> > >>> So I'm OK with this, but it does need a release note warning whenever it
> > >>> goes in, because it'll surprise those who've already enabled nesting
> > >>> but don't use it on all their VMs.
> > >>>
> > >>
> > >> We are hitting this in Fedora 30. Now that nested VMX is enabled by
> > >> default at the kernel level, and virt-manager/boxes will use the
> > >> equivalent of -cpu host by default, libvirt managedsave (migrate to
> > >> file) and virt-manager snapshots (savevm) are rejected for default
> > >> created VMs on intel. That's quite unfortunate.
> > >>
> > >> Any ideas on how to resolve this?
> > > 
> > > I think the simplest solution is just to finish implementation of nested
> > > VMX live migration and backport it to Fedora 30.
> > > 
> > 
> > That would simplify things :) Any guess on the timeframe? This is kernel
> > work I presume?
> 
> No, the kernel part is already in. As a contingency plan, you could just 
> revert this QEMU patch.

With a new-enough kernel, how hard is it to detect that this actual
migration is safe?

Dave

> Paolo
> 
> > 
> > If changes aren't landing in the near term I think we should disable
> > nested VMX by default in Fedora, maybe just with modules.d/kvm.conf
> > override. (Or revert this patch downstream, but I presume that's not a
> > good idea).
> > 
> > The alternative of just letting it sit is going to generate a lot of
> > complaints I suspect. And the only solutions will be 1) disable nested
> > VMx for your whole machine and reboot, or 2) run this virt-xml command
> > to disable VMX in your domain config... and probably forget that it's
> > there and then a year later when this is all sorted out file a bug
> > asking why nested virt isn't working for this one VM ;)
> > 
> > I guess #2 might not be avoidable anyways for the amount of people that
> > have already opted into nested VMX
> > 
> > Thanks,
> > Cole
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK