On Tue, Jul 13, 2010 at 11:14:13AM +0100, Daniel P. Berrange wrote: > On Tue, Jul 13, 2010 at 12:03:43PM +0200, Jiri Denemark wrote: > > Hi Dan, > > > > > I do not compare CPUs for fun, but rather to know if a guest can be run > > > on a specific host. However, this is not exactly what > > > virConnectCompareCPU gives me: A vmx-enabled host cpu is a superset of > > > itself, but it would not run itself as a guest since we do not have > > > nested vxm yet. Similarly, if we ever have svm-emulation-by-kvm, we > > > could be running svm guests on a vmx host. > > > > > > Is it only me? Or should libvirt expose the more interesting meaning? > > > > Absolutely, that would be just perfect. However, I believe libvirt does the > > best it can. Only hypervisor itself knows that it can emulate some features > > which are not present in host CPU or that some features cannot work in guests > > even though host CPU provides them. For such advanced comparison, qemu would > > need to provide a way for libvirt to ask for this stuff. > > Yep, we would need a different API for this, because we would need to be > able to pass in more data than we curently do. eg the machine type, the > emulator binary path, virtualization type (kvm/qemu/xen) etc. It might be > easiest to just have an API that takes the full domain XML instead of just > the CPU XML snipoet Would it make sense to implement this by a VIR_DOMAIN_CHECK_COMPATIBILITY flag to virDomainCreateXML? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list