8:05 a.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--