On Wed, Mar 01, 2017 at 04:33:36PM +0100, Jiri Denemark wrote:
> On Wed, Mar 01, 2017 at 10:14:10 -0500, John Ferlan wrote:
[...]
> Well, unless we have a way to reset the parameters we can't really use
> TLS migration anyway.
>
> > > I think you had this part correctly in the previous version. The Prepare
> > > phase should only call qemuMigrationDelTLSObjects in case of error. The
> > > Finish phase is where all the cleanup after a migration is done.
> >
> > I'll look at what I changed
>
> The previous version specified the objects on QEMU command line when. I
> think calling qemuMigrationDelTLSObjectsin the cleanup part of
> qemuMigrationPrepareAny only in case of error should fix the issue (I
> haven't tried it though).
>
> > Sounds easy if you've done it before many times... It's not something I
> > do every day nor have I done once for libvirt before... ;-) I assumed
> > one really needed two hosts - I assume configuring two guests means
> > setting up nested virt, but that's something else I haven't done...
>
> Not necessarily. You can start a type="qemu" domain inside the guests.
> Anyway, to enable nested virt, just load kvm-intel module with nested=1
> (AMD should have nested enabled by default) and then you need to make
> sure vmx (or svm for AMD) CPU feature is enabled. For example, with the
> following CPU XML added to the guests' definition:
>
> <cpu>
> <model>Skylake-Client</model>
> <feature policy='require' name='vmx'/>
> </cpu>
Or if desired pass-through the host CPU model:
$ virt-xml guest-hyp --edit --cpu host-passthrough,clearxml=yes
Reboot, and don't forget to check /dev/kvm char device exists inside the
L1 guest.
Full notes:
https://kashyapc.fedorapeople.org/virt/procedure-to-enable-nested-virt-on-intel-machines.txt
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
