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 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list