From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 4:10:13 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 04:59 PM, Laszlo Hornyak wrote:
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken(a)redhat.com>
>> To: "Yaniv Kaul" <ykaul(a)redhat.com>
>> Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>,
"engine-devel"
>> <engine-devel(a)ovirt.org>
>> Sent: Wednesday, December 5, 2012 3:22:18 PM
>> Subject: Re: [Engine-devel] host cpu feature
>>
>> On Wed, Dec 05, 2012 at 04:05:00PM +0200, Yaniv Kaul wrote:
>>> On 12/05/2012 03:55 PM, Laszlo Hornyak wrote:
>>>>>>> The nice thing about hostModel (unlike hostPassthrough) is
>>>>>>> that
>>>>>>> once
>>>>>>> we
>>>>>>> created the VM we can migrate it to stronger hosts, and
back
>>>>>>> to
>>>>>>> the
>>>>>>> original host. I suppose that it complicates the scheduler.
>>>>>> Yes with host-model you get the features that libvirt handles.
>>>>>> In
>>>>>> such cases the engine could decide, if you want this
>>>>>> functionality. Well the scheduler architecture is just being
>>>>>> reinvented.
>>>>>>
>>>>>> For the host-passthrough, I think the AllowMigrateCPUHost
>>>>>> configuration option would be a simple decision for the
>>>>>> administrator: set it to true if all hosts are uniform.
>> If it is THAT simple, Engine could take this decision without
>> human
>> intervension.
> Is there a way engine can figure out if the cpu-models in all the
> hosts are the same?
> I mean even if some host flags are not handled by libvirt and
> therefore vdsm and engine...
> So I would really need that permission from the user.
>
>>>>>> If it is
>>>>>> not set to true, then we will not allow migration of such VMs.
>>>>> That's not what I understood from libvirt's documentation.
I
>>>> You may be right, could you send an URL to that point of the
>>>> documentation or copy-paste?
>>> The link I followed from your feature page:
>>>
http://libvirt.org/formatdomain.html#elementsCPU :
>>>
>>> host-model
>>> The host-model mode is essentially a shortcut to copying host CPU
>>> definition from capabilities XML into domain XML. Since the CPU
>>> definition is copied just before starting a domain, exactly the
>>> same
>>> XML can be used on different hosts while still providing the best
>>> guest CPU each host supports. Neither match attribute nor any
>>> feature elements can be used in this mode. Specifying CPU model
>>> is
>>> not supported either, but model's fallback attribute may still be
>>> used. Libvirt does not model every aspect of each CPU so the
>>> guest
>>> CPU will not match the host CPU exactly. On the other hand, the
>>> ABI
>>> provided to the guest is reproducible. During migration, complete
>>> CPU model definition is transferred to the destination host so
>>> the
>>> migrated guest will see exactly the same CPU model even if the
>>> destination host contains more capable CPUs for the running
>>> instance
>>> of the guest; but shutting down and restarting the guest may
>>> present
>>> different hardware to the guest according to the capabilities of
>>> the
>>> new host.
>>> host-passthrough
>>> With this mode, the CPU visible to the guest should be exactly
>>> the
>>> same as the host CPU even in the aspects that libvirt does not
>>> understand. Though the downside of this mode is that the guest
>>> environment cannot be reproduced on different hardware. Thus, if
>>> you
>>> hit any bugs, you are on your own.
>> That's exactly where AllowMigrateCPUHost fits well: when a user
>> ticks
>> this for a cluster he says "yeah, I like to be on my own."
>>
> cpu mode="host-passthrough" migration: I talked to the libvirt guys
> and they said it is OK if the hardware and the software are the
> same, and it will work, but they would not recommend.
>
> So if they do not recommend it, I would drop this from the feature
> spec. Anyone against it?
>
> Laszlo
I'm a bit against it. I don't see why it's that complicated:
Allow migration -> use 'host-model'
Do not allow -> use 'host-passthrough'.
So the actual cpu capabilities would depend not only on the 'host cpu' checkbox,
but also on the 'pinned to host' checkbox. I think this logical trick would be
both funny and confusing from the user's perspective.
The reason of why we need host-passthrough is that otherwise I
suspect
we depend on libvirt for newer features to be somehow exposed to the
guest (not sure about it).