[libvirt-users] caps->nguests == 0?
hi, I compiled the libvirt-0.9.10 and started the libvirtd with sudo. Unfortunately, I got an Error, saying 'virDomainDefParseXML unknown OS type hvm'. I debugged it and found in function virCapabilitiesSupportsGuestOSType, the parameter caps->nguests is 0. On the other hand, I tried start the libvirtd with common user, and creating domain with virsh, i found the caps->ngusts is 2 and had one value 'hvm', so it didn't complain the error above, instead, it complained could not load PC BIOS bios.bin. I'd say I searched a lot and people say it's caused by without loading kvm and kvm-intel module. So, I checked and it is loaded. Any tips here?
On 06/19/2012 02:56 PM, Zhihua Che wrote:
hi,
I compiled the libvirt-0.9.10 and started the libvirtd with sudo. Unfortunately, I got an Error, saying 'virDomainDefParseXML unknown OS type hvm'. I debugged it and found in function virCapabilitiesSupportsGuestOSType, the parameter caps->nguests is 0. On the other hand, I tried start the libvirtd with common user, and creating domain with virsh, i found the caps->ngusts is 2 and had one value 'hvm', so it didn't complain the error above, instead, it complained could not load PC BIOS bios.bin.
I'd say I searched a lot and people say it's caused by without loading kvm and kvm-intel module. So, I checked and it is loaded. Any tips here? Please check libvirtd.log further, if you saw the following similar error:
xxxx : xxxx : error : qemuCapsComputeCmdFlags:1209 : unsupported configuration: this qemu binary requires libvirt to be compiled with yajl xxxx : xxxx : error : virDomainDefParseXML:8312 : internal error No guest options available for arch 'x86_64' It means you need to install yajl-devel rpm package, for more, you may run './configure -h': # ./configure -h | grep yajl --with-yajl use YAJL for JSON parsing/formatting [default=check] BTW, If you're compiling a current libvirt upstream, you will get a friendly reminder, so suggest to try latest libvirt upstream.
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
2012/6/19 Alex Jia <ajia@redhat.com>:
On 06/19/2012 02:56 PM, Zhihua Che wrote:
hi,
I compiled the libvirt-0.9.10 and started the libvirtd with sudo. Unfortunately, I got an Error, saying 'virDomainDefParseXML unknown OS type hvm'. I debugged it and found in function virCapabilitiesSupportsGuestOSType, the parameter caps->nguests is 0. On the other hand, I tried start the libvirtd with common user, and creating domain with virsh, i found the caps->ngusts is 2 and had one value 'hvm', so it didn't complain the error above, instead, it complained could not load PC BIOS bios.bin.
I'd say I searched a lot and people say it's caused by without loading kvm and kvm-intel module. So, I checked and it is loaded. Any tips here?
Please check libvirtd.log further, if you saw the following similar error:
xxxx : xxxx : error : qemuCapsComputeCmdFlags:1209 : unsupported configuration: this qemu binary requires libvirt to be compiled with yajl xxxx : xxxx : error : virDomainDefParseXML:8312 : internal error No guest options available for arch 'x86_64'
It means you need to install yajl-devel rpm package, for more, you may run './configure -h':
# ./configure -h | grep yajl --with-yajl use YAJL for JSON parsing/formatting [default=check]
BTW, If you're compiling a current libvirt upstream, you will get a friendly reminder, so suggest to try latest libvirt upstream.
I hack the code and I guess find the bug... But I wonder how this happened. First, I'm sorry I forgot to mention that I installed my qemu-system-x86_64 in a non-default path, that is, NOT in /usr/bin, /usr/local/bin etc. In this case, if I started up libvirtd with sudo, qemuCapsInitGuest failed to add hvm guest os type to driver->capabilities because it can't find qemu-system-x86_64 by searching environmental variable PATH!. But, the most confusing thing happened here. I've added the qemu-system-x86_64 in PATH by editing the /etc/bash.bashrc. Why can't it still find the qemu?. I found in qemuCapsInitGuest->virFindFileInPath(info->binary) that the call to getenv("PATH") didn't return the path I added myself!
On 06/19/2012 03:20 AM, Zhihua Che wrote:
First, I'm sorry I forgot to mention that I installed my qemu-system-x86_64 in a non-default path, that is, NOT in /usr/bin, /usr/local/bin etc. In this case, if I started up libvirtd with sudo, qemuCapsInitGuest failed to add hvm guest os type to driver->capabilities because it can't find qemu-system-x86_64 by searching environmental variable PATH!.
But, the most confusing thing happened here. I've added the qemu-system-x86_64 in PATH by editing the /etc/bash.bashrc. Why can't it still find the qemu?. I found in qemuCapsInitGuest->virFindFileInPath(info->binary) that the call to getenv("PATH") didn't return the path I added myself!
Remember, 'sudo' sanitizes PATH. Just because you added the directory to _your_ PATH, under your uid, does not mean that the sanitized PATH used by sudo and user root is the same, unless you take explicit actions to set PATH as part of your sudo environment setup. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
2012/6/20 Eric Blake <eblake@redhat.com>:
On 06/19/2012 03:20 AM, Zhihua Che wrote:
First, I'm sorry I forgot to mention that I installed my qemu-system-x86_64 in a non-default path, that is, NOT in /usr/bin, /usr/local/bin etc. In this case, if I started up libvirtd with sudo, qemuCapsInitGuest failed to add hvm guest os type to driver->capabilities because it can't find qemu-system-x86_64 by searching environmental variable PATH!.
But, the most confusing thing happened here. I've added the qemu-system-x86_64 in PATH by editing the /etc/bash.bashrc. Why can't it still find the qemu?. I found in qemuCapsInitGuest->virFindFileInPath(info->binary) that the call to getenv("PATH") didn't return the path I added myself!
Remember, 'sudo' sanitizes PATH. Just because you added the directory to _your_ PATH, under your uid, does not mean that the sanitized PATH used by sudo and user root is the same, unless you take explicit actions to set PATH as part of your sudo environment setup.
--
Yes, I found this issue. Thanks
participants (3)
-
Alex Jia -
Eric Blake -
Zhihua Che