5 Dec
2012
5 Dec
'12
8:45 a.m.
On 12/05/2012 03:39 PM, Laszlo Hornyak wrote: > > ----- Original Message ----- >> From: "Dan Kenigsberg" <danken@redhat.com> >> To: "Laszlo Hornyak" <lhornyak@redhat.com> >> Cc: "Yaniv Kaul" <ykaul@redhat.com>, "engine-devel" <engine-devel@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@redhat.com> >>>> To: "Laszlo Hornyak" <lhornyak@redhat.com> >>>> Cc: "engine-devel" <engine-devel@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@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?