<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3"> </HEAD> <BODY> On Sat, 2008-07-12 at 11:13 +0100, Daniel P. Berrange wrote: <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> Agree - just making the point that it's probably better to collect it just in case. But it sounds like you're saying that rather expose all the data to the end user you'd abstract that within libvirt. <BLOCKQUOTE TYPE=CITE> <PRE> 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. </PRE> </BLOCKQUOTE> Absolutely - that's where it belongs. So then a management tool could query the information and use it to better plan the architecture of clusters grouping "compatible" machines together. <BLOCKQUOTE TYPE=CITE> <PRE> > 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 </PRE> </BLOCKQUOTE> Yeah it really belongs in the silicon, Intel FlexMigration sounds interesting for that reason, but all I know is what their marketing folks tell me :-) <BLOCKQUOTE TYPE=CITE> <PRE> Daniel </PRE> </BLOCKQUOTE> </BODY> </HTML>