[libvirt-users] compilation error
Hello I'm trying to compile libvirt-0.8.6 on RHEL4 with kernel 2.6.9-67 The make command returns: -------------------- util/interface.c: In function `ifaceGetVlanID': util/interface.c:355: error: `GET_VLAN_VID_CMD' undeclared (first use in this function) util/interface.c:355: error: (Each undeclared identifier is reported only once util/interface.c:355: error: for each function it appears in.) make[3]: *** [libvirt_util_la-interface.lo] Error 1 make[3]: Leaving directory `/root/InstalledPackages/libvirt-0.8.6/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/InstalledPackages/libvirt-0.8.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/InstalledPackages/libvirt-0.8.6' make: *** [all] Error 2 -------------------- I have saw that GET_VLAN_VID_CMD should be in if_vlan.h file, but it is not present. What do I have to update in my system to avoid this error? Thanks in advance regards Antoni Artigues
On Wed, Jan 26, 2011 at 11:57:22AM +0100, antoni artigues wrote:
Hello
I'm trying to compile libvirt-0.8.6 on RHEL4 with kernel 2.6.9-67
Ouch, in general libvirt and virtualization was added only in RHEL-5 and while we are trying to make sure libvirt still compile on that platform, we never made any attempt to support RHEL-4, simply because there is also nothing to support (no xen, qemu ...)
The make command returns: -------------------- util/interface.c: In function `ifaceGetVlanID': util/interface.c:355: error: `GET_VLAN_VID_CMD' undeclared (first use in this function) util/interface.c:355: error: (Each undeclared identifier is reported only once util/interface.c:355: error: for each function it appears in.) make[3]: *** [libvirt_util_la-interface.lo] Error 1 make[3]: Leaving directory `/root/InstalledPackages/libvirt-0.8.6/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/InstalledPackages/libvirt-0.8.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/InstalledPackages/libvirt-0.8.6' make: *** [all] Error 2 --------------------
I have saw that GET_VLAN_VID_CMD should be in if_vlan.h file, but it is not present.
What do I have to update in my system to avoid this error?
I still wonder about the usefulness of libvirt on RHEL-4 (except maybe for the client library part). On my RHEL-4 box, GET_VLAN_VID_CMD is nowhere to be found, I'm afraid that will be true for many other parts of libvirt system support on a 2.6.9 linux kernel. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 27/01/2011, at 4:27 PM, Daniel Veillard wrote: <snip>
I still wonder about the usefulness of libvirt on RHEL-4 (except maybe for the client library part).
That's a really good point. Antoni, what are you wanting to do with libvirt? If you want the libvirt server to run... that's probably never going to work. But if you're only needing the libvirt client to run, so you can connect from it to other servers, that's something we should probably think about letting work. :) Regards and best wishes, Justin Clift
Hello Yes. I want to run only the libvirt client. I want to connect from it to manage vmware ESX servers on the cluster nodes. But we must hurry up. So, I think we can't wait for your solution.When would be the improvement? Thank for the answers regards Antoni Artigues El jue, 27-01-2011 a las 19:55 +1100, Justin Clift escribió:
On 27/01/2011, at 4:27 PM, Daniel Veillard wrote: <snip>
I still wonder about the usefulness of libvirt on RHEL-4 (except maybe for the client library part).
That's a really good point. Antoni, what are you wanting to do with libvirt?
If you want the libvirt server to run... that's probably never going to work.
But if you're only needing the libvirt client to run, so you can connect from it to other servers, that's something we should probably think about letting work. :)
Regards and best wishes,
Justin Clift
On 27/01/2011, at 8:11 PM, antoni artigues wrote:
Hello
Yes. I want to run only the libvirt client. I want to connect from it to manage vmware ESX servers on the cluster nodes.
But we must hurry up. So, I think we can't wait for your solution.When would be the improvement?
That's one of those "it's hard to tell things". However, you might be in luck. :) Because you're just needing the libvirt client, there's a chance that the broken pieces are in an option you don't need. So, try turning off the compiling for as many options as possible, using configure switches. Using this kind of approach: $ ./configure --with-libvirtd=no (add more options here if needed) It will mean a bit of experimentation on your part, but it's worth trying. Btw, one of the important options to turn off is the macvtap one, The macvtap code seem to directly use the function you mention is broken, so avoid that one. You ok to try this out? Regards and best wishes, Justin Clift
Okey!! Thank you for the answer. I'm trying to compile with your recommendations. I will post here the experiment results. Thanks Antoni Artigues El jue, 27-01-2011 a las 21:29 +1100, Justin Clift escribió:
On 27/01/2011, at 8:11 PM, antoni artigues wrote:
Hello
Yes. I want to run only the libvirt client. I want to connect from it to manage vmware ESX servers on the cluster nodes.
But we must hurry up. So, I think we can't wait for your solution.When would be the improvement?
That's one of those "it's hard to tell things".
However, you might be in luck. :)
Because you're just needing the libvirt client, there's a chance that the broken pieces are in an option you don't need.
So, try turning off the compiling for as many options as possible, using configure switches. Using this kind of approach:
$ ./configure --with-libvirtd=no (add more options here if needed)
It will mean a bit of experimentation on your part, but it's worth trying.
Btw, one of the important options to turn off is the macvtap one, The macvtap code seem to directly use the function you mention is broken, so avoid that one.
You ok to try this out?
Regards and best wishes,
Justin Clift
Hello I have tried to compile with the minimum number of options. But still the same error: CC libvirt_util_la-interface.lo util/interface.c: In function `ifaceGetVlanID': util/interface.c:355: error: `GET_VLAN_VID_CMD' undeclared (first use in this function) As you can see, only the ESX driver is enabled in the configuration: ------------------- configure: Drivers configure: configure: Xen: no configure: Proxy: no configure: QEMU: no configure: UML: no configure: OpenVZ: no configure: VBox: no configure: XenAPI: no configure: LXC: no configure: PHYP: no configure: ONE: no configure: ESX: yes configure: Test: no configure: Remote: no configure: Network: no configure: Libvirtd: no configure: netcf: no configure: macvtap: no configure: virtport: no configure: configure: Storage Drivers configure: configure: Dir: no configure: FS: no configure: NetFS: no configure: LVM: no configure: iSCSI: no configure: SCSI: no configure: mpath: no configure: Disk: no configure: configure: Security Drivers configure: configure: SELinux: no configure: AppArmor: no configure: configure: Driver Loadable Modules configure: configure: dlopen: no configure: configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 -lpthread -lz -lm configure: libcurl: -DCURL_DISABLE_TYPECHECK -I/usr/local/include -L/usr/local/lib -lcurl configure: libssh2: configure: gnutls: -lgnutls -lgcrypt configure: sasl: no configure: yajl: no configure: avahi: no configure: polkit: no configure: selinux: no configure: apparmor: no configure: numactl: no configure: capng: no configure: xen: no configure: xenapi: no configure: hal: no configure: udev: no configure: netcf: no configure: xmlrpc: no configure: pcap: no configure: nl: no --------------------------------- So, I think is not possible to compile libvirt client on RHEL4. thanks anyway Antoni Artigues El jue, 27-01-2011 a las 21:29 +1100, Justin Clift escribió:
On 27/01/2011, at 8:11 PM, antoni artigues wrote:
Hello
Yes. I want to run only the libvirt client. I want to connect from it to manage vmware ESX servers on the cluster nodes.
But we must hurry up. So, I think we can't wait for your solution.When would be the improvement?
That's one of those "it's hard to tell things".
However, you might be in luck. :)
Because you're just needing the libvirt client, there's a chance that the broken pieces are in an option you don't need.
So, try turning off the compiling for as many options as possible, using configure switches. Using this kind of approach:
$ ./configure --with-libvirtd=no (add more options here if needed)
It will mean a bit of experimentation on your part, but it's worth trying.
Btw, one of the important options to turn off is the macvtap one, The macvtap code seem to directly use the function you mention is broken, so avoid that one.
You ok to try this out?
Regards and best wishes,
Justin Clift
If you only need the ESX part you can disable most of the parts that may have problems due to the old kernel version. Running configure like Justin suggested: ./configure --with-esx --without-libvirtd --without-network This will disable libvirtd, the network driver and probably other things. configure will disable other things like macvtap automatically when it doesn't detect support for them in your system. The compile error you see can easily by avoided by this patch: diff --git a/src/util/interface.c b/src/util/interface.c index fe58823..1463574 100644 --- a/src/util/interface.c +++ b/src/util/interface.c @@ -348,7 +348,7 @@ ifaceGetIndex(bool reportError, #endif /* __linux__ */ -#ifdef __linux__ +#if 0 int ifaceGetVlanID(const char *vlanifname, int *vlanid) { struct vlan_ioctl_args vlanargs = { As ifaceGetVlanID is only used in macvtap specific code that'll probably be disabled anyway because of the kernel version. Matthias 2011/1/27 antoni artigues <tartigues@iac3.eu>:
Hello
Yes. I want to run only the libvirt client. I want to connect from it to manage vmware ESX servers on the cluster nodes.
But we must hurry up. So, I think we can't wait for your solution.When would be the improvement?
Thank for the answers
regards
Antoni Artigues
El jue, 27-01-2011 a las 19:55 +1100, Justin Clift escribió:
On 27/01/2011, at 4:27 PM, Daniel Veillard wrote: <snip>
I still wonder about the usefulness of libvirt on RHEL-4 (except maybe for the client library part).
That's a really good point. Antoni, what are you wanting to do with libvirt?
If you want the libvirt server to run... that's probably never going to work.
But if you're only needing the libvirt client to run, so you can connect from it to other servers, that's something we should probably think about letting work. :)
Regards and best wishes,
Justin Clift
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Hello Thank you for the answer Now, with this patch, and only ESX enabled returns a different error: -------------------------------------- Making all in daemon make[2]: Entering directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make all-am make[3]: Entering directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make[3]: *** No rule to make target `libvirtd.8', needed by `all-am'. Stop. make[3]: Leaving directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/InstalledPackages/libvirt-0.8.3' make: *** [all] Error 2 -------------------------------------- It seems a libvirtd error, but libvirtd is not enabled: "configure: Libvirtd: no" I don't know why returns a libvirtd error. Is there another patch to solve this? Thanks in advance Antoni Artigues El jue, 27-01-2011 a las 14:06 +0100, Matthias Bolte escribió:
If you only need the ESX part you can disable most of the parts that may have problems due to the old kernel version. Running configure like Justin suggested:
./configure --with-esx --without-libvirtd --without-network
This will disable libvirtd, the network driver and probably other things. configure will disable other things like macvtap automatically when it doesn't detect support for them in your system.
The compile error you see can easily by avoided by this patch:
diff --git a/src/util/interface.c b/src/util/interface.c index fe58823..1463574 100644 --- a/src/util/interface.c +++ b/src/util/interface.c @@ -348,7 +348,7 @@ ifaceGetIndex(bool reportError,
#endif /* __linux__ */
-#ifdef __linux__ +#if 0 int ifaceGetVlanID(const char *vlanifname, int *vlanid) { struct vlan_ioctl_args vlanargs = {
As ifaceGetVlanID is only used in macvtap specific code that'll probably be disabled anyway because of the kernel version.
Matthias
2011/1/27 antoni artigues <tartigues@iac3.eu>:
Hello
Yes. I want to run only the libvirt client. I want to connect from it to manage vmware ESX servers on the cluster nodes.
But we must hurry up. So, I think we can't wait for your solution.When would be the improvement?
Thank for the answers
regards
Antoni Artigues
El jue, 27-01-2011 a las 19:55 +1100, Justin Clift escribió:
On 27/01/2011, at 4:27 PM, Daniel Veillard wrote: <snip>
I still wonder about the usefulness of libvirt on RHEL-4 (except maybe for the client library part).
That's a really good point. Antoni, what are you wanting to do with libvirt?
If you want the libvirt server to run... that's probably never going to work.
But if you're only needing the libvirt client to run, so you can connect from it to other servers, that's something we should probably think about letting work. :)
Regards and best wishes,
Justin Clift
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
2011/1/27 antoni artigues <tartigues@iac3.eu>:
Hello
Thank you for the answer
Now, with this patch, and only ESX enabled returns a different error:
-------------------------------------- Making all in daemon make[2]: Entering directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make all-am make[3]: Entering directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make[3]: *** No rule to make target `libvirtd.8', needed by `all-am'. Stop. make[3]: Leaving directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/InstalledPackages/libvirt-0.8.3/daemon' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/InstalledPackages/libvirt-0.8.3' make: *** [all] Error 2 --------------------------------------
It seems a libvirtd error, but libvirtd is not enabled:
"configure: Libvirtd: no"
I don't know why returns a libvirtd error. Is there another patch to solve this?
That's a bug in libvirt 0.8.3 that was fixed in 0.8.4 by this commit: http://libvirt.org/git/?p=libvirt.git;a=commit;h=e7e9456bb4cce02dda7749434fe... Matthias
On 28/01/2011, at 2:35 AM, Matthias Bolte wrote: <snip>
That's a bug in libvirt 0.8.3 that was fixed in 0.8.4 by this commit:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=e7e9456bb4cce02dda7749434fe...
On that note, Antoni, are you able to try with our most recent release, 0.8.7? (you'd need to apply Matthias' patch again though)
Hello Thanks again for all the help. Now with the patch and 0.8.7, and only ESX enabled returns this error: ---------------------------------- virsh-virsh.o(.text+0x128a8): In function `cmdCPUBaseline': : undefined reference to `xmlSaveToBuffer' collect2: ld returned 1 exit status make[3]: *** [virsh] Error 1 make[3]: Leaving directory `/root/InstalledPackages/libvirt-0.8.7/tools' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/InstalledPackages/libvirt-0.8.7/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/InstalledPackages/libvirt-0.8.7' make: *** [all] Error 2 ----------------------------------- Thanks in advance Antoni Artigues El vie, 28-01-2011 a las 02:55 +1100, Justin Clift escribió:
On 28/01/2011, at 2:35 AM, Matthias Bolte wrote: <snip>
That's a bug in libvirt 0.8.3 that was fixed in 0.8.4 by this commit:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=e7e9456bb4cce02dda7749434fe...
On that note, Antoni, are you able to try with our most recent release, 0.8.7? (you'd need to apply Matthias' patch again though)
On 28/01/2011, at 7:21 PM, antoni artigues wrote:
Hello
Thanks again for all the help.
Now with the patch and 0.8.7, and only ESX enabled returns this error:
---------------------------------- virsh-virsh.o(.text+0x128a8): In function `cmdCPUBaseline': : undefined reference to `xmlSaveToBuffer' collect2: ld returned 1 exit status <snip>
Hey Daniel, any idea if there's a reasonable alternative to xmlSaveToBuffer(), that would work with older releases of libxml2? (ie the RHEL4 version) Regards and best wishes, Justin Clift
2011/1/28 Justin Clift <jclift@redhat.com>:
On 28/01/2011, at 7:21 PM, antoni artigues wrote:
Hello
Thanks again for all the help.
Now with the patch and 0.8.7, and only ESX enabled returns this error:
---------------------------------- virsh-virsh.o(.text+0x128a8): In function `cmdCPUBaseline': : undefined reference to `xmlSaveToBuffer' collect2: ld returned 1 exit status <snip>
Hey Daniel, any idea if there's a reasonable alternative to xmlSaveToBuffer(), that would work with older releases of libxml2? (ie the RHEL4 version)
Regards and best wishes,
Justin Clift
Well, we could just do the same as for the kernel version problem, just remove the offending code from virsh.c as the cpu-baseline command is currently not supported for ESX anyway :) I attached a patch that just removes the entire cpu-baseline command from virsh, quite harsh but effective. Matthias
Okey!! Good!! now has compiled without errors. I'm going to check if can manage our esx hypevisors. Thanks to all Regards Antoni Artigues El vie, 28-01-2011 a las 10:48 +0100, Matthias Bolte escribió:
2011/1/28 Justin Clift <jclift@redhat.com>:
On 28/01/2011, at 7:21 PM, antoni artigues wrote:
Hello
Thanks again for all the help.
Now with the patch and 0.8.7, and only ESX enabled returns this error:
---------------------------------- virsh-virsh.o(.text+0x128a8): In function `cmdCPUBaseline': : undefined reference to `xmlSaveToBuffer' collect2: ld returned 1 exit status <snip>
Hey Daniel, any idea if there's a reasonable alternative to xmlSaveToBuffer(), that would work with older releases of libxml2? (ie the RHEL4 version)
Regards and best wishes,
Justin Clift
Well, we could just do the same as for the kernel version problem, just remove the offending code from virsh.c as the cpu-baseline command is currently not supported for ESX anyway :)
I attached a patch that just removes the entire cpu-baseline command from virsh, quite harsh but effective.
Matthias
participants (4)
-
antoni artigues -
Daniel Veillard -
Justin Clift -
Matthias Bolte