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