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