----- Original Message ----- > From: "Yaniv Kaul" <yk...@redhat.com> > To: "Laszlo Hornyak" <lhorn...@redhat.com> > Cc: "Dan Kenigsberg" <dan...@redhat.com>, "engine-devel" > <engine-devel@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" <yk...@redhat.com> To: "Laszlo Hornyak" > <lhorn...@redhat.com> Cc: "Dan Kenigsberg" <dan...@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" <dan...@redhat.com> To: "Laszlo Hornyak" > <lhorn...@redhat.com> Cc: "Yaniv Kaul" <yk...@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" <yk...@redhat.com> To: "Laszlo Hornyak" > <lhorn...@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? > 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? > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel