On Wed, Dec 05, 2012 at 04:05:00PM +0200, Yaniv Kaul wrote: > On 12/05/2012 03:55 PM, Laszlo Hornyak wrote: > > > >>>> > >>>>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 THAT simple, Engine could take this decision without human intervension. > >>>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. That's exactly where AllowMigrateCPUHost fits well: when a user ticks this for a cluster he says "yeah, I like to be on my own." _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
