4:57 a.m.
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
11:27 p.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
2:55 a.m.
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
3:11 a.m.
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
4:29 a.m.
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
5:22 a.m.
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
6:29 a.m.
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
7:06 a.m.
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
9:17 a.m.
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(a)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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
9:35 a.m.
2011/1/27 antoni artigues <tartigues(a)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=e7e9456bb4cce02dda774943...
Matthias
9:55 a.m.
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=e7e9456bb4cce02dda774943...
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)
2:21 a.m.
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=e7e9456bb4cce02dda774943...
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)
2:37 a.m.
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
3:48 a.m.
2011/1/28 Justin Clift <jclift(a)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
5:14 a.m.
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(a)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
5049
days inactive
5051
days old
16 comments
4 participants
participants (4)
-
antoni artigues -
Daniel Veillard -
Justin Clift -
Matthias Bolte