[Ovirt-devel] [PATCH] Adding NIC details to ovirt identify stage.

[Daniel P. Berrange]

On Fri, Jul 11, 2008 at 05:31:39PM -0400, Andrew Cathrow wrote:
> 
> On Fri, 2008-07-11 at 22:22 +0100, Daniel P. Berrange wrote:
> 
> 
> > No, it only currently exposes VMX, SVM and PAE flags.  Why exactly does
> > oVirt need the full set ? They're a forever changing set  across processor
> > vendors and models and architectures which makes them fairly useless as
> > a whole. Specific applications typically only care about specific flags
> > hence we only exposed the ones clearly virt related so far
> 
> Other flags would be useful for verifying migration support. If we
> pulled back the full set of flags then we'd have a baseline of
> information to use in working out which hosts a guest can be migrated
> to.

This doesn't require the full set of flags - if you compare the full
set every time you want to migrate you will be overly restricting
your migration pool.

> For example if a guest is running on a host that has SSE2 then we
> wouldn't want to live migrate that to a host that didn't have this
> feature as it would probably choke. 

SSE is just a handful of the available flags.

> Obviously the logic behind working out what would and wouldn't work is
> horrific, but if we pull back this data at least we have a foundation to
> work on if we decided to go down that path.

I'm inclined to think we want to put as much of this CPU compatability
logic as possible into a libvirt API, or capabilities XML. Any app
using libvirt's migration API will ned todo this check so we should
provide a centralized piece of logic for it. We don't want every app
to have to repeat the logic of figuring out compatible CPUs.

> VMware has done some work on this - for example allowing the NX bit to
> be masked, and have added some more cpu bitmasking features in 3.5, but
> I've not looked too closely into them.

Yep, Xen and KVM have both talked of CPU feature masking but not really
gone anywhere with it so far because its such a troublesome problem to
manage

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|