On 15/04/19 13:22, Dr. David Alan Gilbert wrote: > * Paolo Bonzini (pbonz...@redhat.com) wrote: >> >> ----- Cole Robinson <crobi...@redhat.com> 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 (pbonz...@redhat.com) 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 <pbonz...@redhat.com> >>>>>> >>>>>> 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?
Not hard, but it would fail whenever the KVM kernel module is loaded, so pretty much for all Linux guests. Paolo
