[Engine-devel] host cpu feature

Wed Dec 5 14:22:24 UTC 2012

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, "engine-devel" <engine-devel at 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 at redhat.com> To: "Laszlo Hornyak"
> <lhornyak at redhat.com> Cc: "Dan Kenigsberg" <danken at redhat.com> ,
> "engine-devel" <engine-devel at 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 at redhat.com> To: "Laszlo Hornyak"
> <lhornyak at redhat.com> Cc: "Yaniv Kaul" <ykaul at redhat.com> ,
> "engine-devel" <engine-devel at 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 at redhat.com> To: "Laszlo Hornyak"
> <lhornyak at redhat.com> Cc: "engine-devel" <engine-devel at 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 at 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?
> 