12:32 p.m.
Hi,
CPU-Host support allows the virtual machines to see and utilize the host's CPU flags,
this enables better performance in VM's, at the price of worse portablity.
http://www.ovirt.org/Features/Cpu-host_Support
Your feedback is welcome!
Thank you,
Laszlo
1:23 p.m.
On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
Hi,
CPU-Host support allows the virtual machines to see and utilize the host's CPU flags,
this enables better performance in VM's, at the price of worse portablity.
http://www.ovirt.org/Features/Cpu-host_Support
Your feedback is welcome!
Thank you,
Laszlo
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
- I assume that when you allow migration, you'd use host-model? This is
not clear from the design. It seems like we VDSM developers can choose
to use either this or passthrough, while in practice we should support both.
- I'm still convinced and commented on both relevat oVirt and libvirt
BZs that we need to add x2apic support to the CPU, regardless of what
the host CPU exposes.
AFAIK, the KVM developers agree with me.
Y.
1:46 p.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 12:23:47 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
> Hi,
>
> CPU-Host support allows the virtual machines to see and utilize the
> host's CPU flags, this enables better performance in VM's, at the
> price of worse portablity.
>
> http://www.ovirt.org/Features/Cpu-host_Support
>
> Your feedback is welcome!
>
> Thank you,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
- I assume that when you allow migration, you'd use host-model? This
is
not clear from the design. It seems like we VDSM developers can
choose
to use either this or passthrough, while in practice we should
support both.
If AllowMigrateCPUHost is set to true (in case you have the same cpu model everywhere in
your DC) migration of such hsots will be enabled. Otherwise it will not be enabled.
- I'm still convinced and commented on both relevat oVirt and libvirt
BZs that we need to add x2apic support to the CPU, regardless of what
the host CPU exposes.
AFAIK, the KVM developers agree with me.
Not quite sure how is this related... could you send some URL's for the bugreports?
Y.
2:31 p.m.
On 12/05/2012 01:46 PM, Laszlo Hornyak wrote:
----- Original Message -----
> From: "Yaniv Kaul" <ykaul(a)redhat.com>
> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 12:23:47 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
>> Hi,
>>
>> CPU-Host support allows the virtual machines to see and utilize the
>> host's CPU flags, this enables better performance in VM's, at the
>> price of worse portablity.
>>
>> http://www.ovirt.org/Features/Cpu-host_Support
>>
>> Your feedback is welcome!
>>
>> Thank you,
>> Laszlo
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> - I assume that when you allow migration, you'd use host-model? This
> is
> not clear from the design. It seems like we VDSM developers can
> choose
> to use either this or passthrough, while in practice we should
> support both.
If AllowMigrateCPUHost is set to true (in case you have the same cpu model everywhere in
your DC) migration of such hsots will be enabled. Otherwise it will not be enabled.
It's not going to help just enabling it - you need to use 'host-model'
and not 'host-passthrough', so there'll be a reasonable chance to
succeed the migration, AFAIK.
> - I'm still convinced and commented on both relevat oVirt and libvirt
> BZs that we need to add x2apic support to the CPU, regardless of what
> the host CPU exposes.
> AFAIK, the KVM developers agree with me.
Not quite sure how is this related... could you send some URL's for the bugreports?
It's related because x2apic improves performance, and so does '-cpu
host', but that doesn't enable x2apic implicitly.
https://bugzilla.redhat.com/show_bug.cgi?id=838469#c7
https://bugzilla.redhat.com/show_bug.cgi?id=700272#c28
Y.
> Y.
>
>
2:55 p.m.
On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
----- Original Message -----
> From: "Yaniv Kaul" <ykaul(a)redhat.com>
> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 12:23:47 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
> > Hi,
> >
> > CPU-Host support allows the virtual machines to see and utilize the
> > host's CPU flags, this enables better performance in VM's, at the
> > price of worse portablity.
> >
> > http://www.ovirt.org/Features/Cpu-host_Support
> >
> > Your feedback is welcome!
> >
> > Thank you,
> > Laszlo
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> - I assume that when you allow migration, you'd use host-model? This
> is
> not clear from the design. It seems like we VDSM developers can
> choose
> to use either this or passthrough, while in practice we should
> support both.
I join Kaul's question: it is an ovirt-level question whether
hostPassthrough or hostModel or both should be supported. It should not
be a unilateral vdsm decision.
If AllowMigrateCPUHost is set to true (in case you have the same cpu model everywhere in
your DC) migration of such hsots will be enabled. Otherwise it will not be enabled.
What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC? Per cluster?
I favor the latter; a user may have a cluster of exact-same hosts, where
hostcpu migration is allowed, and other cluster where it is forbiden.
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.
>
> - I'm still convinced and commented on both relevat oVirt and libvirt
> BZs that we need to add x2apic support to the CPU, regardless of what
> the host CPU exposes.
> AFAIK, the KVM developers agree with me.
Not quite sure how is this related... could you send some URL's for the bugreports?
3:39 p.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
Cc: "Yaniv Kaul" <ykaul(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 1:55:19 PM
Subject: Re: [Engine-devel] host cpu feature
On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
>
>
> ----- Original Message -----
> > From: "Yaniv Kaul" <ykaul(a)redhat.com>
> > To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > Sent: Wednesday, December 5, 2012 12:23:47 PM
> > Subject: Re: [Engine-devel] host cpu feature
> >
> > On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
> > > Hi,
> > >
> > > CPU-Host support allows the virtual machines to see and utilize
> > > the
> > > host's CPU flags, this enables better performance in VM's, at
> > > the
> > > price of worse portablity.
> > >
> > > http://www.ovirt.org/Features/Cpu-host_Support
> > >
> > > Your feedback is welcome!
> > >
> > > Thank you,
> > > Laszlo
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> > - I assume that when you allow migration, you'd use host-model?
> > This
> > is
> > not clear from the design. It seems like we VDSM developers can
> > choose
> > to use either this or passthrough, while in practice we should
> > support both.
I join Kaul's question: it is an ovirt-level question whether
hostPassthrough or hostModel or both should be supported. It should
not
be a unilateral vdsm decision.
Ah, possibly misunderstanding, I did not mean that VDSM should decide whether to use
host-passthrough or host-model. The engine should decide.
I meant _you_ should decide which version of vdsm api modification do you want :)
>
> If AllowMigrateCPUHost is set to true (in case you have the same
> cpu model everywhere in your DC) migration of such hsots will be
> enabled. Otherwise it will not be enabled.
What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC? Per
cluster?
I thought of eninge-wide. The of course you can have different models in two different DC,
but they should be unique in one.
We can add this to DC or cluster level, imho it would be just another checkbox on the UI
that most users would not use.
I favor the latter; a user may have a cluster of exact-same hosts,
where
hostcpu migration is allowed, and other cluster where it is forbiden.
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
not set to true, then we will not allow migration of such VMs.
>
> >
> > - I'm still convinced and commented on both relevat oVirt and
> > libvirt
> > BZs that we need to add x2apic support to the CPU, regardless of
> > what
> > the host CPU exposes.
> > AFAIK, the KVM developers agree with me.
>
> Not quite sure how is this related... could you send some URL's for
> the bugreports?
3:45 p.m.
On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> Cc: "Yaniv Kaul" <ykaul(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 1:55:19 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
>>
>> ----- Original Message -----
>>> From: "Yaniv Kaul" <ykaul(a)redhat.com>
>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>> Sent: Wednesday, December 5, 2012 12:23:47 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>> On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
>>>> Hi,
>>>>
>>>> CPU-Host support allows the virtual machines to see and utilize
>>>> the
>>>> host's CPU flags, this enables better performance in VM's, at
>>>> the
>>>> price of worse portablity.
>>>>
>>>> http://www.ovirt.org/Features/Cpu-host_Support
>>>>
>>>> Your feedback is welcome!
>>>>
>>>> Thank you,
>>>> Laszlo
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>> - I assume that when you allow migration, you'd use host-model?
>>> This
>>> is
>>> not clear from the design. It seems like we VDSM developers can
>>> choose
>>> to use either this or passthrough, while in practice we should
>>> support both.
> I join Kaul's question: it is an ovirt-level question whether
> hostPassthrough or hostModel or both should be supported. It should
> not
> be a unilateral vdsm decision.
Ah, possibly misunderstanding, I did not mean that VDSM should decide whether to use
host-passthrough or host-model. The engine should decide.
I meant _you_ should decide which version of vdsm api modification do you want :)
>> If AllowMigrateCPUHost is set to true (in case you have the same
>> cpu model everywhere in your DC) migration of such hsots will be
>> enabled. Otherwise it will not be enabled.
> What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC? Per
> cluster?
I thought of eninge-wide. The of course you can have different models in two different
DC, but they should be unique in one.
We can add this to DC or cluster level, imho it would be just another checkbox on the UI
that most users would not use.
> I favor the latter; a user may have a cluster of exact-same hosts,
> where
> hostcpu migration is allowed, and other cluster where it is forbiden.
>
> 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
not set to true, then we will not allow migration of such VMs.
That's not what I understood from libvirt's documentation. I understood
that if you want host+migration, you need to use host-model. Otherwise -
host-passthrough.
Y.
>>> - I'm still convinced and commented on both relevat oVirt and
>>> libvirt
>>> BZs that we need to add x2apic support to the CPU, regardless of
>>> what
>>> the host CPU exposes.
>>> AFAIK, the KVM developers agree with me.
>> Not quite sure how is this related... could you send some URL's for
>> the bugreports?
3:55 p.m.
----- Original Message -----
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 2:45:46 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken(a)redhat.com>
>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>> Cc: "Yaniv Kaul" <ykaul(a)redhat.com>, "engine-devel"
>> <engine-devel(a)ovirt.org>
>> Sent: Wednesday, December 5, 2012 1:55:19 PM
>> Subject: Re: [Engine-devel] host cpu feature
>>
>> On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul(a)redhat.com>
>>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>>> Sent: Wednesday, December 5, 2012 12:23:47 PM
>>>> Subject: Re: [Engine-devel] host cpu feature
>>>>
>>>> On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
>>>>> Hi,
>>>>>
>>>>> CPU-Host support allows the virtual machines to see and utilize
>>>>> the
>>>>> host's CPU flags, this enables better performance in VM's,
at
>>>>> the
>>>>> price of worse portablity.
>>>>>
>>>>> http://www.ovirt.org/Features/Cpu-host_Support
>>>>>
>>>>> Your feedback is welcome!
>>>>>
>>>>> Thank you,
>>>>> Laszlo
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> - I assume that when you allow migration, you'd use host-model?
>>>> This
>>>> is
>>>> not clear from the design. It seems like we VDSM developers can
>>>> choose
>>>> to use either this or passthrough, while in practice we should
>>>> support both.
>> I join Kaul's question: it is an ovirt-level question whether
>> hostPassthrough or hostModel or both should be supported. It
>> should
>> not
>> be a unilateral vdsm decision.
> Ah, possibly misunderstanding, I did not mean that VDSM should
> decide whether to use host-passthrough or host-model. The engine
> should decide.
> I meant _you_ should decide which version of vdsm api modification
> do you want :)
>
>>> If AllowMigrateCPUHost is set to true (in case you have the same
>>> cpu model everywhere in your DC) migration of such hsots will be
>>> enabled. Otherwise it will not be enabled.
>> What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC?
>> Per
>> cluster?
> I thought of eninge-wide. The of course you can have different
> models in two different DC, but they should be unique in one.
> We can add this to DC or cluster level, imho it would be just
> another checkbox on the UI that most users would not use.
>
>> I favor the latter; a user may have a cluster of exact-same hosts,
>> where
>> hostcpu migration is allowed, and other cluster where it is
>> forbiden.
>>
>> 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
> 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?
understood
that if you want host+migration, you need to use host-model.
Otherwise -
host-passthrough.
Y.
>
>>>> - I'm still convinced and commented on both relevat oVirt and
>>>> libvirt
>>>> BZs that we need to add x2apic support to the CPU, regardless of
>>>> what
>>>> the host CPU exposes.
>>>> AFAIK, the KVM developers agree with me.
>>> Not quite sure how is this related... could you send some URL's
>>> for
>>> the bugreports?
4:05 p.m.
This is a multi-part message in MIME format.
--------------090702030407000604010506
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 12/05/2012 03:55 PM, Laszlo Hornyak wrote:
----- Original Message -----
> 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 2:45:46 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
>> ----- Original Message -----
>>> From: "Dan Kenigsberg" <danken(a)redhat.com>
>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> Cc: "Yaniv Kaul" <ykaul(a)redhat.com>,
"engine-devel"
>>> <engine-devel(a)ovirt.org>
>>> Sent: Wednesday, December 5, 2012 1:55:19 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>> On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
>>>> ----- Original Message -----
>>>>> From: "Yaniv Kaul" <ykaul(a)redhat.com>
>>>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>>>> Sent: Wednesday, December 5, 2012 12:23:47 PM
>>>>> Subject: Re: [Engine-devel] host cpu feature
>>>>>
>>>>> On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
>>>>>> Hi,
>>>>>>
>>>>>> CPU-Host support allows the virtual machines to see and utilize
>>>>>> the
>>>>>> host's CPU flags, this enables better performance in
VM's, at
>>>>>> the
>>>>>> price of worse portablity.
>>>>>>
>>>>>> http://www.ovirt.org/Features/Cpu-host_Support
>>>>>>
>>>>>> Your feedback is welcome!
>>>>>>
>>>>>> Thank you,
>>>>>> Laszlo
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> - I assume that when you allow migration, you'd use host-model?
>>>>> This
>>>>> is
>>>>> not clear from the design. It seems like we VDSM developers can
>>>>> choose
>>>>> to use either this or passthrough, while in practice we should
>>>>> support both.
>>> I join Kaul's question: it is an ovirt-level question whether
>>> hostPassthrough or hostModel or both should be supported. It
>>> should
>>> not
>>> be a unilateral vdsm decision.
>> Ah, possibly misunderstanding, I did not mean that VDSM should
>> decide whether to use host-passthrough or host-model. The engine
>> should decide.
>> I meant _you_ should decide which version of vdsm api modification
>> do you want :)
>>
>>>> If AllowMigrateCPUHost is set to true (in case you have the same
>>>> cpu model everywhere in your DC) migration of such hsots will be
>>>> enabled. Otherwise it will not be enabled.
>>> What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC?
>>> Per
>>> cluster?
>> I thought of eninge-wide. The of course you can have different
>> models in two different DC, but they should be unique in one.
>> We can add this to DC or cluster level, imho it would be just
>> another checkbox on the UI that most users would not use.
>>
>>> I favor the latter; a user may have a cluster of exact-same hosts,
>>> where
>>> hostcpu migration is allowed, and other cluster where it is
>>> forbiden.
>>>
>>> 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
>> 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. Neither model nor feature elements are allowed in this mode.
Y.
> understood
> that if you want host+migration, you need to use host-model.
> Otherwise -
> host-passthrough.
> Y.
>
>>>>> - I'm still convinced and commented on both relevat oVirt and
>>>>> libvirt
>>>>> BZs that we need to add x2apic support to the CPU, regardless of
>>>>> what
>>>>> the host CPU exposes.
>>>>> AFAIK, the KVM developers agree with me.
>>>> Not quite sure how is this related... could you send some URL's
>>>> for
>>>> the bugreports?
>
--------------090702030407000604010506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/05/2012 03:55 PM, Laszlo Hornyak
wrote:<br>
</div>
<blockquote
cite="mid:310221607.5986866.1354715753473.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Yaniv Kaul" <a
class="moz-txt-link-rfc2396E"
href="mailto:ykaul@redhat.com"><ykaul@redhat.com></a>
To: "Laszlo Hornyak" <a class="moz-txt-link-rfc2396E"
href="mailto:lhornyak@redhat.com"><lhornyak@redhat.com></a>
Cc: "Dan Kenigsberg" <a class="moz-txt-link-rfc2396E"
href="mailto:danken@redhat.com"><danken@redhat.com></a>,
"engine-devel" <a class="moz-txt-link-rfc2396E"
href="mailto:engine-devel@ovirt.org"><engine-devel@ovirt.org></a>
Sent: Wednesday, December 5, 2012 2:45:46 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Dan Kenigsberg" <a
class="moz-txt-link-rfc2396E"
href="mailto:danken@redhat.com"><danken@redhat.com></a>
To: "Laszlo Hornyak" <a class="moz-txt-link-rfc2396E"
href="mailto:lhornyak@redhat.com"><lhornyak@redhat.com></a>
Cc: "Yaniv Kaul" <a class="moz-txt-link-rfc2396E"
href="mailto:ykaul@redhat.com"><ykaul@redhat.com></a>,
"engine-devel"
<a class="moz-txt-link-rfc2396E"
href="mailto:engine-devel@ovirt.org"><engine-devel@ovirt.org></a>
Sent: Wednesday, December 5, 2012 1:55:19 PM
Subject: Re: [Engine-devel] host cpu feature
On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Yaniv Kaul" <a
class="moz-txt-link-rfc2396E"
href="mailto:ykaul@redhat.com"><ykaul@redhat.com></a>
To: "Laszlo Hornyak" <a class="moz-txt-link-rfc2396E"
href="mailto:lhornyak@redhat.com"><lhornyak@redhat.com></a>
Cc: "engine-devel" <a class="moz-txt-link-rfc2396E"
href="mailto:engine-devel@ovirt.org"><engine-devel@ovirt.org></a>
Sent: Wednesday, December 5, 2012 12:23:47 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
CPU-Host support allows the virtual machines to see and utilize
the
host's CPU flags, this enables better performance in VM's, at
the
price of worse portablity.
<a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Features/Cpu-host_Support">http:/...
Your feedback is welcome!
Thank you,
Laszlo
_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<pre wrap="">- I assume that when you allow migration,
you'd use host-model?
This
is
not clear from the design. It seems like we VDSM developers can
choose
to use either this or passthrough, while in practice we should
support both.
</pre>
</blockquote>
</blockquote>
<pre wrap="">I join Kaul's question: it is an ovirt-level
question whether
hostPassthrough or hostModel or both should be supported. It
should
not
be a unilateral vdsm decision.
</pre>
</blockquote>
<pre wrap="">Ah, possibly misunderstanding, I did not mean that
VDSM should
decide whether to use host-passthrough or host-model. The engine
should decide.
I meant _you_ should decide which version of vdsm api modification
do you want :)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If AllowMigrateCPUHost is set to true (in case
you have the same
cpu model everywhere in your DC) migration of such hsots will be
enabled. Otherwise it will not be enabled.
</pre>
</blockquote>
<pre wrap="">What is the breadth of AllowMigrateCPUHost?
Engine wide? Per DC?
Per
cluster?
</pre>
</blockquote>
<pre wrap="">I thought of eninge-wide. The of course you can
have different
models in two different DC, but they should be unique in one.
We can add this to DC or cluster level, imho it would be just
another checkbox on the UI that most users would not use.
</pre>
<blockquote type="cite">
<pre wrap="">I favor the latter; a user may have a cluster of
exact-same hosts,
where
hostcpu migration is allowed, and other cluster where it is
forbiden.
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.
</pre>
</blockquote>
<pre wrap="">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
not set to true, then we will not allow migration of such VMs.
</pre>
</blockquote>
<pre wrap="">
That's not what I understood from libvirt's documentation. I
</pre>
</blockquote>
<pre wrap="">
You may be right, could you send an URL to that point of the documentation or
copy-paste?</pre>
</blockquote>
<br>
The link I followed from your feature page:
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<a
href="http://libvirt.org/formatdomain.html#elementsCPU">http...
:<br>
<br>
host-model<br>
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.<br>
host-passthrough<br>
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. Neither model nor feature
elements are allowed in this mode.<br>
<br>
<br>
Y.<br>
<br>
<blockquote
cite="mid:310221607.5986866.1354715753473.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">understood
that if you want host+migration, you need to use host-model.
Otherwise -
host-passthrough.
Y.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- I'm still convinced and commented on
both relevat oVirt and
libvirt
BZs that we need to add x2apic support to the CPU, regardless of
what
the host CPU exposes.
AFAIK, the KVM developers agree with me.
</pre>
</blockquote>
<pre wrap="">Not quite sure how is this related... could you
send some URL's
for
the bugreports?
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------090702030407000604010506--
4:22 p.m.
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.
>>>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."
4:59 p.m.
----- 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
5:10 p.m.
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'.
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).
Y.
5:24 p.m.
----- Original Message -----
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).
Yes, with other words: this is a tuning feature.
Y.
6:33 p.m.
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
To: "Yaniv Kaul" <ykaul(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 5:24:59 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
> 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).
Yes, with other words: this is a tuning feature.
Let's keep it simple.
1. Please remove AllowMigrateCPUHost. No reason for us to do what libvirt is asking to
void.
2. host-passthrough should be available only for non migratable VMs.
> Y.
>
>
>
>
6:41 p.m.
----- Original Message -----
From: "Doron Fediuck" <dfediuck(a)redhat.com>
To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv Kaul"
<ykaul(a)redhat.com>
Sent: Wednesday, December 5, 2012 5:33:35 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> To: "Yaniv Kaul" <ykaul(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 5:24:59 PM
> Subject: Re: [Engine-devel] host cpu feature
>
>
> ----- Original Message -----
> > 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).
>
> Yes, with other words: this is a tuning feature.
>
Let's keep it simple.
1. Please remove AllowMigrateCPUHost. No reason for us to do what
libvirt is asking to void.
With pleasure :)
2. host-passthrough should be available only for non migratable VMs.
Right.
And no host-model support for now, right?
> > Y.
> >
> >
> >
> >
6:46 p.m.
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
To: "Doron Fediuck" <dfediuck(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv Kaul"
<ykaul(a)redhat.com>
Sent: Wednesday, December 5, 2012 6:41:24 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
> From: "Doron Fediuck" <dfediuck(a)redhat.com>
> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv Kaul"
> <ykaul(a)redhat.com>
> Sent: Wednesday, December 5, 2012 5:33:35 PM
> Subject: Re: [Engine-devel] host cpu feature
>
>
>
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > To: "Yaniv Kaul" <ykaul(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > Sent: Wednesday, December 5, 2012 5:24:59 PM
> > Subject: Re: [Engine-devel] host cpu feature
> >
> >
> > ----- Original Message -----
> > > 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).
> >
> > Yes, with other words: this is a tuning feature.
> >
>
> Let's keep it simple.
> 1. Please remove AllowMigrateCPUHost. No reason for us to do what
> libvirt is asking to void.
With pleasure :)
> 2. host-passthrough should be available only for non migratable
> VMs.
Right.
And no host-model support for now, right?
Right.
In can later be added if we have a good reasoning for it.
>
>
> > > Y.
> > >
> > >
> > >
> > >
>
6:48 p.m.
On 12/05/2012 06:46 PM, Doron Fediuck wrote:
----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> To: "Doron Fediuck" <dfediuck(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv Kaul"
<ykaul(a)redhat.com>
> Sent: Wednesday, December 5, 2012 6:41:24 PM
> Subject: Re: [Engine-devel] host cpu feature
>
>
>
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck(a)redhat.com>
>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv
Kaul"
>> <ykaul(a)redhat.com>
>> Sent: Wednesday, December 5, 2012 5:33:35 PM
>> Subject: Re: [Engine-devel] host cpu feature
>>
>>
>>
>> ----- Original Message -----
>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> To: "Yaniv Kaul" <ykaul(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>> Sent: Wednesday, December 5, 2012 5:24:59 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>>
>>> ----- Original Message -----
>>>> 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).
>>> Yes, with other words: this is a tuning feature.
>>>
>> Let's keep it simple.
>> 1. Please remove AllowMigrateCPUHost. No reason for us to do what
>> libvirt is asking to void.
> With pleasure :)
>
>> 2. host-passthrough should be available only for non migratable
>> VMs.
> Right.
>
> And no host-model support for now, right?
>
Right.
In can later be added if we have a good reasoning for it.
Alternative idea, inspired by "Thus, if you hit any bugs, you are on
your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
'host-passthrough'):
A config option to determine if we use host-model or host-passthrough.
Y.
>>
>>>> Y.
>>>>
>>>>
>>>>
>>>>
7:10 p.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Doron Fediuck" <dfediuck(a)redhat.com>
Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 6:48:33 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 06:46 PM, Doron Fediuck wrote:
>
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>> To: "Doron Fediuck" <dfediuck(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv
Kaul"
>> <ykaul(a)redhat.com>
>> Sent: Wednesday, December 5, 2012 6:41:24 PM
>> Subject: Re: [Engine-devel] host cpu feature
>>
>>
>>
>> ----- Original Message -----
>>> From: "Doron Fediuck" <dfediuck(a)redhat.com>
>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv
Kaul"
>>> <ykaul(a)redhat.com>
>>> Sent: Wednesday, December 5, 2012 5:33:35 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>>> To: "Yaniv Kaul" <ykaul(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>>> Sent: Wednesday, December 5, 2012 5:24:59 PM
>>>> Subject: Re: [Engine-devel] host cpu feature
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> 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).
>>>> Yes, with other words: this is a tuning feature.
>>>>
>>> Let's keep it simple.
>>> 1. Please remove AllowMigrateCPUHost. No reason for us to do what
>>> libvirt is asking to void.
>> With pleasure :)
>>
>>> 2. host-passthrough should be available only for non migratable
>>> VMs.
>> Right.
>>
>> And no host-model support for now, right?
>>
> Right.
> In can later be added if we have a good reasoning for it.
Alternative idea, inspired by "Thus, if you hit any bugs, you are on
your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
'host-passthrough'):
A config option to determine if we use host-model or
host-passthrough.
Y.
I do not think the engine should go to this level.
ie- it can ask for passthrough as a feature, and the
actual implementation is handled by vdsm.
7:13 p.m.
On 12/05/2012 07:10 PM, Doron Fediuck wrote:
----- Original Message -----
> From: "Yaniv Kaul" <ykaul(a)redhat.com>
> To: "Doron Fediuck" <dfediuck(a)redhat.com>
> Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 6:48:33 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> On 12/05/2012 06:46 PM, Doron Fediuck wrote:
>> ----- Original Message -----
>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> To: "Doron Fediuck" <dfediuck(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv
Kaul"
>>> <ykaul(a)redhat.com>
>>> Sent: Wednesday, December 5, 2012 6:41:24 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Doron Fediuck" <dfediuck(a)redhat.com>
>>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yaniv
Kaul"
>>>> <ykaul(a)redhat.com>
>>>> Sent: Wednesday, December 5, 2012 5:33:35 PM
>>>> Subject: Re: [Engine-devel] host cpu feature
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>>>> To: "Yaniv Kaul" <ykaul(a)redhat.com>
>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>>>> Sent: Wednesday, December 5, 2012 5:24:59 PM
>>>>> Subject: Re: [Engine-devel] host cpu feature
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> 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).
>>>>> Yes, with other words: this is a tuning feature.
>>>>>
>>>> Let's keep it simple.
>>>> 1. Please remove AllowMigrateCPUHost. No reason for us to do what
>>>> libvirt is asking to void.
>>> With pleasure :)
>>>
>>>> 2. host-passthrough should be available only for non migratable
>>>> VMs.
>>> Right.
>>>
>>> And no host-model support for now, right?
>>>
>> Right.
>> In can later be added if we have a good reasoning for it.
> Alternative idea, inspired by "Thus, if you hit any bugs, you are on
> your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
> 'host-passthrough'):
> A config option to determine if we use host-model or
> host-passthrough.
> Y.
>
I do not think the engine should go to this level.
IMHO, it's not the engine, it's the user - the advanced user. But even
an advanced user won't go and change VDSM's logic.
Lets hope that host-passthrough is well tested.
Y.
ie- it can ask for passthrough as a feature, and the
actual implementation is handled by vdsm.
7:14 p.m.
----- Original Message -----
From: "Doron Fediuck" <dfediuck(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 6:10:55 PM
Subject: Re: [Engine-devel] host cpu feature
> Alternative idea, inspired by "Thus, if you hit any bugs, you are
> on
> your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
> 'host-passthrough'):
> A config option to determine if we use host-model or
> host-passthrough.
> Y.
>
I do not think the engine should go to this level.
ie- it can ask for passthrough as a feature, and the
actual implementation is handled by vdsm.
If vdsm decides over host-passthrough or host-model, then how will the engine user know
what exactly his VM gets. I think vdsm must be told exactly what to do.
7:37 p.m.
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
To: "Doron Fediuck" <dfediuck(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 7:14:46 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
> From: "Doron Fediuck" <dfediuck(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 6:10:55 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> > Alternative idea, inspired by "Thus, if you hit any bugs, you are
> > on
> > your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
> > 'host-passthrough'):
> > A config option to determine if we use host-model or
> > host-passthrough.
> > Y.
> >
>
> I do not think the engine should go to this level.
> ie- it can ask for passthrough as a feature, and the
> actual implementation is handled by vdsm.
>
If vdsm decides over host-passthrough or host-model, then how will
the engine user know what exactly his VM gets. I think vdsm must be
told exactly what to do.
VDSM maintains some level of independence. This is why it the engine
should be able to ask for passthrough as a feature. Otherwize vdsm will
handle it. So for now I suggest we stick to passthrough only, and if
we get an RFE for advanced mode we'll support the host model.
9:15 p.m.
Quoting Doron Fediuck <dfediuck(a)redhat.com>:
----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> To: "Doron Fediuck" <dfediuck(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 7:14:46 PM
> Subject: Re: [Engine-devel] host cpu feature
>
>
>
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck(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 6:10:55 PM
> > Subject: Re: [Engine-devel] host cpu feature
> >
> > > Alternative idea, inspired by "Thus, if you hit any bugs, you are
> > > on
> > > your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
> > > 'host-passthrough'):
> > > A config option to determine if we use host-model or
> > > host-passthrough.
> > > Y.
> > >
> >
> > I do not think the engine should go to this level.
> > ie- it can ask for passthrough as a feature, and the
> > actual implementation is handled by vdsm.
> >
>
> If vdsm decides over host-passthrough or host-model, then how will
> the engine user know what exactly his VM gets. I think vdsm must be
> told exactly what to do.
>
VDSM maintains some level of independence. This is why it the engine
should be able to ask for passthrough as a feature. Otherwize vdsm will
handle it. So for now I suggest we stick to passthrough only, and if
we get an RFE for advanced mode we'll support the host model.
What are we gaining by using passthrough over host-model? Looking at
libvirt documentation, it seems that both modes give host CPU
capabilities to guest VM. Whereas the downside of passthrough is that
it limits migration. Whereas host-model will migrate to other hardware
and if the destination hardware is better than source then the guest
VM performance can be improved by rebooting guest.
As a stretch goal, ovirt can keep track of host capabilities and
inform the user after migrating to a better host, that a reboot may
improve guest performance.
Regards
Sharad Mishra
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:56 p.m.
On 12/05/2012 09:15 PM, snmishra(a)linux.vnet.ibm.com wrote:
Quoting Doron Fediuck <dfediuck(a)redhat.com>:
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>> To: "Doron Fediuck" <dfediuck(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>> Sent: Wednesday, December 5, 2012 7:14:46 PM
>> Subject: Re: [Engine-devel] host cpu feature
>>
>>
>>
>> ----- Original Message -----
>> > From: "Doron Fediuck" <dfediuck(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 6:10:55 PM
>> > Subject: Re: [Engine-devel] host cpu feature
>> >
>> > > Alternative idea, inspired by "Thus, if you hit any bugs, you are
>> > > on
>> > > your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
>> > > 'host-passthrough'):
>> > > A config option to determine if we use host-model or
>> > > host-passthrough.
>> > > Y.
>> > >
>> >
>> > I do not think the engine should go to this level.
>> > ie- it can ask for passthrough as a feature, and the
>> > actual implementation is handled by vdsm.
>> >
>>
>> If vdsm decides over host-passthrough or host-model, then how will
>> the engine user know what exactly his VM gets. I think vdsm must be
>> told exactly what to do.
>>
>
> VDSM maintains some level of independence. This is why it the engine
> should be able to ask for passthrough as a feature. Otherwize vdsm will
> handle it. So for now I suggest we stick to passthrough only, and if
> we get an RFE for advanced mode we'll support the host model.
What are we gaining by using passthrough over host-model? Looking at
libvirt documentation, it seems that both modes give host CPU
capabilities to guest VM. Whereas the downside of passthrough is that it
limits migration. Whereas host-model will migrate to other hardware and
if the destination hardware is better than source then the guest VM
performance can be improved by rebooting guest.
As a stretch goal, ovirt can keep track of host capabilities and inform
the user after migrating to a better host, that a reboot may improve
guest performance.
pass-through may give better performance.
host-model would be relevant when we can support live migration inside
the cluster for some of the nodes, which will be relevant when the
scheduler is more pluggable/extendable than today.
11:20 a.m.
Thank you all for your feedback, I moved the feature to implementation status.
Patches:
- engine http://gerrit.ovirt.org/#/c/9753/
- vdsm: http://gerrit.ovirt.org/#/c/9507/ (engine patch is built on this)
- or alternative vdsm: http://gerrit.ovirt.org/#/c/9367/ (vdsm guys still need to decide
which one do they want)
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: snmishra(a)linux.vnet.ibm.com
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 9:56:02 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 09:15 PM, snmishra(a)linux.vnet.ibm.com wrote:
>
> Quoting Doron Fediuck <dfediuck(a)redhat.com>:
>
>> ----- Original Message -----
>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> To: "Doron Fediuck" <dfediuck(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>> Sent: Wednesday, December 5, 2012 7:14:46 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: "Doron Fediuck" <dfediuck(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 6:10:55 PM
>>> > Subject: Re: [Engine-devel] host cpu feature
>>> >
>>> > > Alternative idea, inspired by "Thus, if you hit any bugs,
you
>>> > > are
>>> > > on
>>> > > your own" (http://libvirt.org/formatdomain.html#elementsCPU
>>> > > wrt
>>> > > 'host-passthrough'):
>>> > > A config option to determine if we use host-model or
>>> > > host-passthrough.
>>> > > Y.
>>> > >
>>> >
>>> > I do not think the engine should go to this level.
>>> > ie- it can ask for passthrough as a feature, and the
>>> > actual implementation is handled by vdsm.
>>> >
>>>
>>> If vdsm decides over host-passthrough or host-model, then how
>>> will
>>> the engine user know what exactly his VM gets. I think vdsm must
>>> be
>>> told exactly what to do.
>>>
>>
>> VDSM maintains some level of independence. This is why it the
>> engine
>> should be able to ask for passthrough as a feature. Otherwize vdsm
>> will
>> handle it. So for now I suggest we stick to passthrough only, and
>> if
>> we get an RFE for advanced mode we'll support the host model.
>
> What are we gaining by using passthrough over host-model? Looking
> at
> libvirt documentation, it seems that both modes give host CPU
> capabilities to guest VM. Whereas the downside of passthrough is
> that it
> limits migration. Whereas host-model will migrate to other hardware
> and
> if the destination hardware is better than source then the guest VM
> performance can be improved by rebooting guest.
>
> As a stretch goal, ovirt can keep track of host capabilities and
> inform
> the user after migrating to a better host, that a reboot may
> improve
> guest performance.
pass-through may give better performance.
host-model would be relevant when we can support live migration
inside
the cluster for some of the nodes, which will be relevant when the
scheduler is more pluggable/extendable than today.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
2:21 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: snmishra(a)linux.vnet.ibm.com
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 3:56:02 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 09:15 PM, snmishra(a)linux.vnet.ibm.com wrote:
>
> Quoting Doron Fediuck <dfediuck(a)redhat.com>:
>
>> ----- Original Message -----
>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>> To: "Doron Fediuck" <dfediuck(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>> Sent: Wednesday, December 5, 2012 7:14:46 PM
>>> Subject: Re: [Engine-devel] host cpu feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>> > From: "Doron Fediuck" <dfediuck(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 6:10:55 PM
>>> > Subject: Re: [Engine-devel] host cpu feature
>>> >
>>> > > Alternative idea, inspired by "Thus, if you hit any bugs,
you
>>> > > are
>>> > > on
>>> > > your own" (http://libvirt.org/formatdomain.html#elementsCPU
>>> > > wrt
>>> > > 'host-passthrough'):
>>> > > A config option to determine if we use host-model or
>>> > > host-passthrough.
>>> > > Y.
>>> > >
>>> >
>>> > I do not think the engine should go to this level.
>>> > ie- it can ask for passthrough as a feature, and the
>>> > actual implementation is handled by vdsm.
>>> >
>>>
>>> If vdsm decides over host-passthrough or host-model, then how
>>> will
>>> the engine user know what exactly his VM gets. I think vdsm must
>>> be
>>> told exactly what to do.
>>>
>>
>> VDSM maintains some level of independence. This is why it the
>> engine
>> should be able to ask for passthrough as a feature. Otherwize vdsm
>> will
>> handle it. So for now I suggest we stick to passthrough only, and
>> if
>> we get an RFE for advanced mode we'll support the host model.
>
> What are we gaining by using passthrough over host-model? Looking
> at
> libvirt documentation, it seems that both modes give host CPU
> capabilities to guest VM. Whereas the downside of passthrough is
> that it
> limits migration. Whereas host-model will migrate to other hardware
> and
> if the destination hardware is better than source then the guest VM
> performance can be improved by rebooting guest.
>
> As a stretch goal, ovirt can keep track of host capabilities and
> inform
> the user after migrating to a better host, that a reboot may
> improve
> guest performance.
pass-through may give better performance.
We need to be using -cpu host aka pass-through for performance. Selecting -cpu host on a
Westmere cpu is different to -cpu Westmere on a Westmere cpu in terms of what the guest
sees
host-model would be relevant when we can support live migration
inside
the cluster for some of the nodes, which will be relevant when the
scheduler is more pluggable/extendable than today.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:22 p.m.
----- Original Message -----
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 3:05:00 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 03:55 PM, Laszlo Hornyak wrote:
----- Original Message -----
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 2:45:46 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com> To: "Laszlo
Hornyak"
<lhornyak(a)redhat.com> Cc: "Yaniv Kaul" <ykaul(a)redhat.com> ,
"engine-devel" <engine-devel(a)ovirt.org> Sent: Wednesday, December 5,
2012 1:55:19 PM
Subject: Re: [Engine-devel] host cpu feature
On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com> To: "Laszlo Hornyak"
<lhornyak(a)redhat.com> Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 12:23:47 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
Hi,
CPU-Host support allows the virtual machines to see and utilize
the
host's CPU flags, this enables better performance in VM's, at
the
price of worse portablity.
http://www.ovirt.org/Features/Cpu-host_Support Your feedback is
welcome!
Thank you,
Laszlo
_______________________________________________
Engine-devel mailing list Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel - I assume that
when you allow migration, you'd use host-model?
This
is
not clear from the design. It seems like we VDSM developers can
choose
to use either this or passthrough, while in practice we should
support both. I join Kaul's question: it is an ovirt-level question
whether
hostPassthrough or hostModel or both should be supported. It
should
not
be a unilateral vdsm decision. Ah, possibly misunderstanding, I did
not mean that VDSM should
decide whether to use host-passthrough or host-model. The engine
should decide.
I meant _you_ should decide which version of vdsm api modification
do you want :)
If AllowMigrateCPUHost is set to true (in case you have the same
cpu model everywhere in your DC) migration of such hsots will be
enabled. Otherwise it will not be enabled. What is the breadth of
AllowMigrateCPUHost? Engine wide? Per DC?
Per
cluster? I thought of eninge-wide. The of course you can have
different
models in two different DC, but they should be unique in one.
We can add this to DC or cluster level, imho it would be just
another checkbox on the UI that most users would not use.
I favor the latter; a user may have a cluster of exact-same hosts,
where
hostcpu migration is allowed, and other cluster where it is
forbiden.
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
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
"Though the downside of this mode is that the guest environment cannot be reproduced
on different hardware"
Ok, what I understand from this is that if the cpu-model is the same on the other host,
then it is OK, other CPU models will likely fail.
I need to talk to libvirt guys about this.
But anyway, I am OK with making host-passthrough VM's pinned to host. In that way I
think it will be easier for the users as well.
hit any bugs, you are on your own. Neither model nor feature
elements are allowed in this mode.
Y.
understood
that if you want host+migration, you need to use host-model.
Otherwise -
host-passthrough.
Y.
- I'm still convinced and commented on both relevat oVirt and
libvirt
BZs that we need to add x2apic support to the CPU, regardless of
what
the host CPU exposes.
AFAIK, the KVM developers agree with me. Not quite sure how is this
related... could you send some URL's
for
the bugreports?
4:16 p.m.
On Wed, Dec 05, 2012 at 08:39:52AM -0500, Laszlo Hornyak wrote:
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> Cc: "Yaniv Kaul" <ykaul(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
> Sent: Wednesday, December 5, 2012 1:55:19 PM
> Subject: Re: [Engine-devel] host cpu feature
>
> On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
> >
> >
> > ----- Original Message -----
> > > From: "Yaniv Kaul" <ykaul(a)redhat.com>
> > > To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
> > > Cc: "engine-devel" <engine-devel(a)ovirt.org>
> > > Sent: Wednesday, December 5, 2012 12:23:47 PM
> > > Subject: Re: [Engine-devel] host cpu feature
> > >
> > > On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
> > > > Hi,
> > > >
> > > > CPU-Host support allows the virtual machines to see and utilize
> > > > the
> > > > host's CPU flags, this enables better performance in VM's,
at
> > > > the
> > > > price of worse portablity.
> > > >
> > > > http://www.ovirt.org/Features/Cpu-host_Support
> > > >
> > > > Your feedback is welcome!
> > > >
> > > > Thank you,
> > > > Laszlo
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > > - I assume that when you allow migration, you'd use host-model?
> > > This
> > > is
> > > not clear from the design. It seems like we VDSM developers can
> > > choose
> > > to use either this or passthrough, while in practice we should
> > > support both.
>
> I join Kaul's question: it is an ovirt-level question whether
> hostPassthrough or hostModel or both should be supported. It should
> not
> be a unilateral vdsm decision.
Ah, possibly misunderstanding, I did not mean that VDSM should decide whether to use
host-passthrough or host-model. The engine should decide.
I meant _you_ should decide which version of vdsm api modification do you want :)
>
> >
> > If AllowMigrateCPUHost is set to true (in case you have the same
> > cpu model everywhere in your DC) migration of such hsots will be
> > enabled. Otherwise it will not be enabled.
>
> What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC? Per
> cluster?
I thought of eninge-wide. The of course you can have different models in two different
DC, but they should be unique in one.
We can add this to DC or cluster level, imho it would be just another checkbox on the UI
that most users would not use.
Most users are not going to use hostcpu. This feature is intended to
people who have performance-critical VMs, and a set of hosts that can
run them. These very same people may have less critical desktops that
are to be allowed to run on any host.
4364
days inactive
4366
days old
26 comments
7 participants
participants (7)
-
Andrew Cathrow -
Dan Kenigsberg -
Doron Fediuck -
Itamar Heim -
Laszlo Hornyak -
snmishraï¼ linux.vnet.ibm.com -
Yaniv Kaul