On 09/10/2013 07:37 AM, Michal Novotny wrote: >> >> If you want to know whether kvm virt is possible or not, then >> query the capabilities XML. >> >> Daniel > > Ok, if this is merely returning the driver name wouldn't it be better to > rename it to virConnectGetDriverName() ? Unfortunately, we don't like renaming APIs if avoidable. It introduces a compat problem where new apps have to decide whether they can use the new name or the old name based on what they are targetting (the old name has to remain in the .so to avoid breaking old apps), whereas having only one name available makes it easier (use just the one name). > According to documentation at > [1] it's the name of the hypervisor so the hypervisor may be both QEMU > or KVM so why to put QEMU if it's the driver name? At least fixing the > documentation with information the function is returning the driver name > used (and you cannot rely on it to know whether you're on KVM or QEMU) > would be nice... The qemu:// URI services both qemu and kvm guests; it's up to the capabilities XML to tell you which (or both) of those types it can serve. But a doc patch is welcome, if it would help reduce your confusion. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list