Open Stack

On 5/31/2016 8:36 AM, Daniel P. Berrange wrote:
> On Tue, May 31, 2016 at 08:19:33AM -0400, Sean Dague wrote:
>> On 05/30/2016 06:25 AM, Kashyap Chamarthy wrote:
>>> On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote:
>>>> On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
>>>>> On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> So, in short, the central issue seems to be this: the custom 'gate64'
>>>>>> model is not being trasnalted by libvirt into a model that QEMU can
>>>>>> recognize.
>>>>>
>>>>> An update:
>>>>>
>>>>> Upstream libvirt points out that this turns to be regression, and
>>>>> bisected it to commit (in libvirt Git): 1.2.9-31-g445a09b -- "qemu:
>>>>> Don't compare CPU against host for TCG".
>>>>>
>>>>> So, I expect there's going to be fix pretty soon upstream libvirt.
>>>>
>>>> Which is good... I wonder how long we'll be waiting for that back in our
>>>> distro packages though.
>>>
>>> Yeah, until the fix lands, our current options seem to be:
>>>
>>>   (a) Revert to a known good version of libvirt
>>
>> Downgrading libvirt so dramatically isn't a thing we'll be able to do.
>>
>>>   (b) Use nested virt (i.e. <domain type='kvm'>) -- I doubt is possible
>>>       on RAX environment, which is using Xen, last I know.
>>
>> We turned off nested virt even where it was enabled, because it locks up
>> at a non trivial rate. So not really an option.
>
> Hmm, if the guest is using 'qemu' and not 'kvm', then there should be
> no dependancy between the host CPU and guest CPU whatsoever. ie we can
> present arbitrary CPU to the guest, whether the host CPU has matching
> features or not.
>
> I wonder if there is a bug in Nova where it is trying todo a host/guest
> CPU compatibility check even for 'qemu' guests, when it should only do
> them for 'kvm' guests.
>
> If we can avoid the CPU compatibility check with qemu guest, then the
> fact that there's a libvirt bug here should be irrelevant, and we could
> avoid needing to invent a gate64 CPU model too.
>
>
> Regards,
> Daniel
>

Sounds like there was a bad check in nova which is fixed here:

https://review.openstack.org/#/c/323467/

And a d-g change depends on that here:

https://review.openstack.org/#/c/320925/

Is there anything more to do for this? I'm assuming we should backport 
the nova change to the stable branches because the d-g change is going 
to break those multinode jobs on stable, although they are already 
non-voting jobs so it doesn't really matter. But if we knowingly break 
those jobs on stable branches, we should fix them to work or exclude 
them from running on stable branch changes since it'd be a waste of test 
resources.

-- 

Thanks,

Matt Riedemann