On Wed, Mar 01, 2017 at 10:14:10 -0500, John Ferlan wrote:
> On 03/01/2017 06:57 AM, Jiri Denemark wrote:
> That jiggled a memory strand... It really wasn't clear from reading
> QEMU's qapi-schema.json description that the Get would return anything
> for tls-{creds,hostname}.
>
> So for determining whether the option exists or not I'm left to other
> options it seems. Even if code is added (in 2.9) to provide something
> like an empty string - that'd have to be backported to 2.8 and 2.7 and
> we'd have to somehow ensure/hope that was applied so that the right
> answer could be returned from Get...
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>
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
