[libvirt] Building on Solaris 11 Express
I would really like to use ZFS's zvols as storage for my guests. I really like ZFS's snapshots, send/receive, and checksumming features. (Compression and deduplication might be useful as well.) I'm roughly about half-way done writing a ZFS storage backend for libvirt. It behaves like the LVM backend. I've been writing it on Linux. However, ZFS on Linux is not yet production-ready. So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far. First, I had to prune down the features being built: I added --without-xen to deal with the following. I wasn't intending on using Xen, so this doesn't bother me personally. configure: error: You must install the Xen development package to compile Xen driver with -lxenstore I added --without-openvz to deal with the following. Likewise, I'm not using it. CC libvirt_driver_openvz_la-openvz_driver.lo openvz/openvz_driver.c:45:19: paths.h: No such file or directory In file included from ../src/conf/domain_conf.h:40, from openvz/openvz_conf.h:33, from openvz/openvz_driver.c:56: ../src/conf/nwfilter_conf.h:521: warning: parameter has incomplete type I added --without-network to deal with the following. I may need to actually fix this at some point. CC libvirt_util_la-bridge.lo util/bridge.c:39:20: paths.h: No such file or directory util/bridge.c:42:55: linux/param.h: No such file or directory util/bridge.c:43:55: linux/sockios.h: No such file or directory util/bridge.c:44:55: linux/if_bridge.h: No such file or directory util/bridge.c:45:55: linux/if_tun.h: No such file or directory util/bridge.c: In function `ifSetInterfaceMac': util/bridge.c:313: error: `SIOCGIFHWADDR' undeclared (first use in this function) util/bridge.c:313: error: (Each undeclared identifier is reported only once util/bridge.c:313: error: for each function it appears in.) util/bridge.c:316: error: structure has no member named `ifr_hwaddr' util/bridge.c:318: error: `SIOCSIFHWADDR' undeclared (first use in this function) util/bridge.c: In function `ifGetMtu': util/bridge.c:347: error: `SIOCGIFMTU' undeclared (first use in this function) util/bridge.c: In function `ifSetMtu': util/bridge.c:378: error: `SIOCSIFMTU' undeclared (first use in this function) util/bridge.c: In function `brAddTap': util/bridge.c:501: error: `IFF_TAP' undeclared (first use in this function) util/bridge.c:501: error: `IFF_NO_PI' undeclared (first use in this function) util/bridge.c:515: error: `TUNSETIFF' undeclared (first use in this function) util/bridge.c:537: error: `TUNSETPERSIST' undeclared (first use in this function) util/bridge.c: In function `brDeleteTap': util/bridge.c:567: error: `IFF_TAP' undeclared (first use in this function) util/bridge.c:567: error: `IFF_NO_PI' undeclared (first use in this function) util/bridge.c:574: error: `TUNSETIFF' undeclared (first use in this function) util/bridge.c:575: error: `TUNSETPERSIST' undeclared (first use in this function) util/bridge.c: In function `brSetInterfaceUp': util/bridge.c:612: error: `SIOCGIFFLAGS' undeclared (first use in this function) util/bridge.c:620: error: `SIOCSIFFLAGS' undeclared (first use in this function) util/bridge.c: In function `brGetInterfaceUp': util/bridge.c:652: error: `SIOCGIFFLAGS' undeclared (first use in this function) Then, I had to fix a trivial code error. I've mailed the patch to this list with a subject of "[PATCH] Fix virExecWithHook Prototype". I also had linker trouble. Solaris 11's gcc package uses Solaris ld, not GNU ld. I had to change the following: VERSION_SCRIPT_FLAGS=-Wl,--version-script= `$LD --help 2>&1 | grep -- --version-script >/dev/null` || \ - VERSION_SCRIPT_FLAGS="-Wl,-M -Wl," + VERSION_SCRIPT_FLAGS="" Interestingly, this code seems to have been added to support Solaris ld according to git blame; see git log c2fb8bfe. I'm not sure what is correct here. At this point, libvirt builds and installs. I tested virsh against a remote system using: virsh -c qemu+ssh://REMOTE/system This worked except for the fact that it was trying to attach to /usr/local/var/run/libvirt-sock on the remote system due to /usr/local being the --prefix used with the *local* virsh was built. I'm not sure how that architectural issue should be addressed. For testing, I just made a /usr/local/var -> /var symlink on the remote system. However, libvirtd will not start locally (on Solaris) which has pretty much stopped my progress. I'm sure this must be something trivial. Is it getting a bad prefix? Is something other than libvirtd supposed to make the socket file? I did try making a /.libvirt directory for testing. # rm /usr/local/var/run/libvirtd.pid ; /usr/local/sbin/libvirtd -v 20:13:33.663: 1: info : libvirt version: 0.9.1 20:13:33.663: 1: error : qemudListenUnix:605 : Failed to bind socket to '@//.libvirt/libvirt-sock': No such file or directory Thanks, Richard
2011/5/29 Richard Laager <rlaager@wiktel.com>:
I would really like to use ZFS's zvols as storage for my guests. I really like ZFS's snapshots, send/receive, and checksumming features. (Compression and deduplication might be useful as well.)
I'm roughly about half-way done writing a ZFS storage backend for libvirt. It behaves like the LVM backend. I've been writing it on Linux. However, ZFS on Linux is not yet production-ready.
Interesting :)
So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
First, I had to prune down the features being built:
I added --without-xen to deal with the following. I wasn't intending on using Xen, so this doesn't bother me personally. configure: error: You must install the Xen development package to compile Xen driver with -lxenstore
That's strange, configure should automatically disable the Xen driver if it can't find the required headers and libs. The only way I can see from the logic in configure is that configure found libxenstore but can't find the headers such as xen/xen.h xen/version.h xen/dom0_ops.h xen/sys/privcmd.h xen/linux/privcmd.h. You can check config.log for the results of those checks. On my Linux system it looks like this: configure:46331: checking for xs_read in -lxenstore configure:46356: gcc -std=gnu99 -o conftest -g -ggdb -O0 conftest.c -lxenstore -ldl >&5 configure:46356: $? = 0 configure:46365: result: yes configure:46387: checking for xen/xen.h configure:46387: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46387: $? = 0 configure:46387: result: yes configure:46387: checking for xen/version.h configure:46387: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46387: $? = 0 configure:46387: result: yes configure:46387: checking for xen/dom0_ops.h configure:46387: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46387: $? = 0 configure:46387: result: yes configure:46415: checking for xen/sys/privcmd.h configure:46415: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46415: $? = 0 configure:46415: result: yes configure:46477: checking sys/inotify.h usability configure:46477: gcc -std=gnu99 -c -g -ggdb -O0 conftest.c >&5 configure:46477: $? = 0 configure:46477: result: yes configure:46477: checking sys/inotify.h presence configure:46477: gcc -E conftest.c configure:46477: $? = 0 configure:46477: result: yes configure found all libs and headers. In you case it probably found libxenstore but at least one of the headers is missing, so one of the results should be "no" in your case.
I added --without-openvz to deal with the following. Likewise, I'm not using it. CC libvirt_driver_openvz_la-openvz_driver.lo openvz/openvz_driver.c:45:19: paths.h: No such file or directory In file included from ../src/conf/domain_conf.h:40, from openvz/openvz_conf.h:33, from openvz/openvz_driver.c:56: ../src/conf/nwfilter_conf.h:521: warning: parameter has incomplete type
configure should disable the OpenVZ driver on Solaris anyway, because OpenVZ is Linux specific. Also paths.h isn't used in here anyway and could be removed. I'll post patches for this.
I added --without-network to deal with the following. I may need to actually fix this at some point. CC libvirt_util_la-bridge.lo util/bridge.c:39:20: paths.h: No such file or directory util/bridge.c:42:55: linux/param.h: No such file or directory util/bridge.c:43:55: linux/sockios.h: No such file or directory util/bridge.c:44:55: linux/if_bridge.h: No such file or directory util/bridge.c:45:55: linux/if_tun.h: No such file or directory util/bridge.c: In function `ifSetInterfaceMac': util/bridge.c:313: error: `SIOCGIFHWADDR' undeclared (first use in this function) util/bridge.c:313: error: (Each undeclared identifier is reported only once util/bridge.c:313: error: for each function it appears in.) util/bridge.c:316: error: structure has no member named `ifr_hwaddr' util/bridge.c:318: error: `SIOCSIFHWADDR' undeclared (first use in this function) util/bridge.c: In function `ifGetMtu': util/bridge.c:347: error: `SIOCGIFMTU' undeclared (first use in this function) util/bridge.c: In function `ifSetMtu': util/bridge.c:378: error: `SIOCSIFMTU' undeclared (first use in this function) util/bridge.c: In function `brAddTap': util/bridge.c:501: error: `IFF_TAP' undeclared (first use in this function) util/bridge.c:501: error: `IFF_NO_PI' undeclared (first use in this function) util/bridge.c:515: error: `TUNSETIFF' undeclared (first use in this function) util/bridge.c:537: error: `TUNSETPERSIST' undeclared (first use in this function) util/bridge.c: In function `brDeleteTap': util/bridge.c:567: error: `IFF_TAP' undeclared (first use in this function) util/bridge.c:567: error: `IFF_NO_PI' undeclared (first use in this function) util/bridge.c:574: error: `TUNSETIFF' undeclared (first use in this function) util/bridge.c:575: error: `TUNSETPERSIST' undeclared (first use in this function) util/bridge.c: In function `brSetInterfaceUp': util/bridge.c:612: error: `SIOCGIFFLAGS' undeclared (first use in this function) util/bridge.c:620: error: `SIOCSIFFLAGS' undeclared (first use in this function) util/bridge.c: In function `brGetInterfaceUp': util/bridge.c:652: error: `SIOCGIFFLAGS' undeclared (first use in this function)
libvirt's virtual network is Linux specific but configure doesn't disable it on non-Linux systems.
Then, I had to fix a trivial code error. I've mailed the patch to this list with a subject of "[PATCH] Fix virExecWithHook Prototype".
I've applied your patch.
At this point, libvirt builds and installs. I tested virsh against a remote system using: virsh -c qemu+ssh://REMOTE/system
This worked except for the fact that it was trying to attach to /usr/local/var/run/libvirt-sock on the remote system due to /usr/local being the --prefix used with the *local* virsh was built. I'm not sure how that architectural issue should be addressed. For testing, I just made a /usr/local/var -> /var symlink on the remote system.
However, libvirtd will not start locally (on Solaris) which has pretty much stopped my progress. I'm sure this must be something trivial. Is it getting a bad prefix? Is something other than libvirtd supposed to make the socket file? I did try making a /.libvirt directory for testing.
# rm /usr/local/var/run/libvirtd.pid ; /usr/local/sbin/libvirtd -v 20:13:33.663: 1: info : libvirt version: 0.9.1 20:13:33.663: 1: error : qemudListenUnix:605 : Failed to bind socket to '@//.libvirt/libvirt-sock': No such file or directory
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern: @<home-directory>/.libvirt/libvirt-sock The @ is later on replace by NUL to indicate that it should go in to the UNIX abstract namespace. It seems that your home directory is set to '/'. libvirt uses getpwuid_r to get the home directory. Maybe there is a Solaris specific problem here. To work around this you can try running libvirtd as root. In that case the UNIX socket will be opened at /usr/local/var/run/libvirt/libvirt-sock in your case. Matthias
On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
I was using 0.9.1. I should switch to git.
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern:
@<home-directory>/.libvirt/libvirt-sock
I was actually running it as root. Richard
2011/5/29 Richard Laager <rlaager@wiktel.com>:
On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
I was using 0.9.1. I should switch to git.
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern:
@<home-directory>/.libvirt/libvirt-sock
I was actually running it as root.
Richard
That's even stranger. libvirtd uses geteuid() == 0 to detect if it's running as root and acts upon that. It only tries to open a UNIX socket in the user's home (what it does in your case) when it detects non-root execution. Something is wrong here, but I've no clue what. Matthias
On Sun, May 29, 2011 at 19:45, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/5/29 Richard Laager <rlaager@wiktel.com>:
On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
I was using 0.9.1. I should switch to git.
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern:
@<home-directory>/.libvirt/libvirt-sock
I was actually running it as root.
Richard
That's even stranger. libvirtd uses geteuid() == 0 to detect if it's running as root and acts upon that. It only tries to open a UNIX socket in the user's home (what it does in your case) when it detects non-root execution. Something is wrong here, but I've no clue what.
Matthias
Only linux supports the abstract socket namespace. I ran into the same issue on OS X (http://www.redhat.com/archives/libvir-list/2010-October/msg00969.html) Kind regards, Ruben
2011/5/30 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Sun, May 29, 2011 at 19:45, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/5/29 Richard Laager <rlaager@wiktel.com>:
On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
I was using 0.9.1. I should switch to git.
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern:
@<home-directory>/.libvirt/libvirt-sock
I was actually running it as root.
Richard
That's even stranger. libvirtd uses geteuid() == 0 to detect if it's running as root and acts upon that. It only tries to open a UNIX socket in the user's home (what it does in your case) when it detects non-root execution. Something is wrong here, but I've no clue what.
Matthias
Only linux supports the abstract socket namespace. I ran into the same issue on OS X (http://www.redhat.com/archives/libvir-list/2010-October/msg00969.html)
Kind regards,
Ruben
Okay, that's a related but different problem, I think. As far as I understood the situation here Richard is running libvirtd as root. In that case libvirt should create the UNIX socket in [/usr/local]/var/run/libvirt/libvirt-sock. Only when running libvirtd as non-root it creates the UNIX socket in the abstract namespace, but not in the roor case. Therefore, running libvirtd as root should work on Solaris. But libvirtd seem to fail to detect being executed as root. It tries to create the UNIX socket in a broken path in the abstract namespace and this fails, but this is just a symptom, not the actual problem. The question is why, libvirtd thinks it's running as non-root while Richard says that he's running it as root. Matthias
On Mon, May 30, 2011 at 08:52, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/5/30 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Sun, May 29, 2011 at 19:45, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/5/29 Richard Laager <rlaager@wiktel.com>:
On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
So I tried building libvirt on Solaris 11 Express. The following outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
I was using 0.9.1. I should switch to git.
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern:
@<home-directory>/.libvirt/libvirt-sock
I was actually running it as root.
Richard
That's even stranger. libvirtd uses geteuid() == 0 to detect if it's running as root and acts upon that. It only tries to open a UNIX socket in the user's home (what it does in your case) when it detects non-root execution. Something is wrong here, but I've no clue what.
Matthias
Only linux supports the abstract socket namespace. I ran into the same issue on OS X (http://www.redhat.com/archives/libvir-list/2010-October/msg00969.html)
Kind regards,
Ruben
Okay, that's a related but different problem, I think.
As far as I understood the situation here Richard is running libvirtd as root. In that case libvirt should create the UNIX socket in [/usr/local]/var/run/libvirt/libvirt-sock. Only when running libvirtd as non-root it creates the UNIX socket in the abstract namespace, but not in the roor case. Therefore, running libvirtd as root should work on Solaris. But libvirtd seem to fail to detect being executed as root. It tries to create the UNIX socket in a broken path in the abstract namespace and this fails, but this is just a symptom, not the actual problem.
The question is why, libvirtd thinks it's running as non-root while Richard says that he's running it as root.
Matthias
It has probably something to do with this piece of code, in daemon/libvirtd.c: #ifdef __sun static int qemudSetupPrivs (void) { chown ("/var/run/libvirt", SYSTEM_UID, SYSTEM_UID); if (__init_daemon_priv (PU_RESETGROUPS | PU_CLEARLIMITSET, SYSTEM_UID, SYSTEM_UID, PRIV_XVM_CONTROL, NULL)) { VIR_ERROR(_("additional privileges are required")); return -1; } if (priv_set (PRIV_OFF, PRIV_ALLSETS, PRIV_FILE_LINK_ANY, PRIV_PROC_INFO, PRIV_PROC_SESSION, PRIV_PROC_EXEC, PRIV_PROC_FORK, NULL)) { VIR_ERROR(_("failed to set reduced privileges")); return -1; } return 0; } #else # define qemudSetupPrivs() 0 #endif This drops the privileges to those of the xvm user (SYSTEM_UID = 60) After that, in qemudInitialize(), geteuid() returns 60 and server->privileged is set to 0. Since server->privileged is 0, we try to create the abstract socket, which causes the error Richard is seeing. This looks like a side-effect from commit a71f79c3 Makes sense? Thanks, Ruben
2011/6/3 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Mon, May 30, 2011 at 08:52, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/5/30 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Sun, May 29, 2011 at 19:45, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/5/29 Richard Laager <rlaager@wiktel.com>:
On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
> So I tried building libvirt on Solaris 11 Express. The following > outlines the trouble (and successes) I've had so far.
I assume your building from up-to-date git here?
I was using 0.9.1. I should switch to git.
'@//.libvirt/libvirt-sock' should actually look like this '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd as non-root it tries to open a UNIX socket in the home directory of the user starting it. This path is build via this pattern:
@<home-directory>/.libvirt/libvirt-sock
I was actually running it as root.
Richard
That's even stranger. libvirtd uses geteuid() == 0 to detect if it's running as root and acts upon that. It only tries to open a UNIX socket in the user's home (what it does in your case) when it detects non-root execution. Something is wrong here, but I've no clue what.
Matthias
Only linux supports the abstract socket namespace. I ran into the same issue on OS X (http://www.redhat.com/archives/libvir-list/2010-October/msg00969.html)
Kind regards,
Ruben
Okay, that's a related but different problem, I think.
As far as I understood the situation here Richard is running libvirtd as root. In that case libvirt should create the UNIX socket in [/usr/local]/var/run/libvirt/libvirt-sock. Only when running libvirtd as non-root it creates the UNIX socket in the abstract namespace, but not in the roor case. Therefore, running libvirtd as root should work on Solaris. But libvirtd seem to fail to detect being executed as root. It tries to create the UNIX socket in a broken path in the abstract namespace and this fails, but this is just a symptom, not the actual problem.
The question is why, libvirtd thinks it's running as non-root while Richard says that he's running it as root.
Matthias
It has probably something to do with this piece of code, in daemon/libvirtd.c:
#ifdef __sun static int qemudSetupPrivs (void) { chown ("/var/run/libvirt", SYSTEM_UID, SYSTEM_UID);
if (__init_daemon_priv (PU_RESETGROUPS | PU_CLEARLIMITSET, SYSTEM_UID, SYSTEM_UID, PRIV_XVM_CONTROL, NULL)) { VIR_ERROR(_("additional privileges are required")); return -1; }
if (priv_set (PRIV_OFF, PRIV_ALLSETS, PRIV_FILE_LINK_ANY, PRIV_PROC_INFO, PRIV_PROC_SESSION, PRIV_PROC_EXEC, PRIV_PROC_FORK, NULL)) { VIR_ERROR(_("failed to set reduced privileges")); return -1; }
return 0; } #else # define qemudSetupPrivs() 0 #endif
This drops the privileges to those of the xvm user (SYSTEM_UID = 60) After that, in qemudInitialize(), geteuid() returns 60 and server->privileged is set to 0. Since server->privileged is 0, we try to create the abstract socket, which causes the error Richard is seeing.
This looks like a side-effect from commit a71f79c3
Makes sense?
Thanks,
Ruben
That might be the problem. I don't have a Solaris at hand right now to test it so here is a speculative patch for this. Matthias
On 06/03/2011 01:11 AM, Matthias Bolte wrote:
That might be the problem. I don't have a Solaris at hand right now to test it so here is a speculative patch for this.
And while I have access to a Solaris machine, I don't have enough pre-requisites built on it in order to build libvirt, so I likewise am not in a position to test. Ruben, it would be nice to have your ACK.
qemudSetupPrivs() drops privileges on Solaris making geteuid() return non-zero later on when qemudInitialize() tries to detect privileged mode.
Detect privileged mode before calling qemudSetupPrivs() to fix this.
In principle, this sounds like the right solution.
@@ -3300,8 +3302,12 @@ int main(int argc, char **argv) { * getuid/geteuid() == 0, for privilege level checks. * It must all use the flag 'server->privileged' * which is also passed into all libvirt stateful - * drivers + * drivers. + * Detect geteuid() == 0 before calling qemudSetupPrivs() + * because that might drop privileges. */ + privileged = geteuid() == 0 ? 1 : 0;
Identical, and simpler, to just write: privileged = !geteuid(); ACK by code inspection, but I'd prefer actual build test before committing this. It qualifies for inclusion in 0.9.2 if we act fast enough, but I don't think it is a show-stopper if we miss out on Solaris builds for this release. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Jun 3, 2011 at 16:16, Eric Blake <eblake@redhat.com> wrote:
On 06/03/2011 01:11 AM, Matthias Bolte wrote:
That might be the problem. I don't have a Solaris at hand right now to test it so here is a speculative patch for this.
And while I have access to a Solaris machine, I don't have enough pre-requisites built on it in order to build libvirt, so I likewise am not in a position to test. Ruben, it would be nice to have your ACK.
qemudSetupPrivs() drops privileges on Solaris making geteuid() return non-zero later on when qemudInitialize() tries to detect privileged mode.
Detect privileged mode before calling qemudSetupPrivs() to fix this.
In principle, this sounds like the right solution.
@@ -3300,8 +3302,12 @@ int main(int argc, char **argv) { * getuid/geteuid() == 0, for privilege level checks. * It must all use the flag 'server->privileged' * which is also passed into all libvirt stateful - * drivers + * drivers. + * Detect geteuid() == 0 before calling qemudSetupPrivs() + * because that might drop privileges. */ + privileged = geteuid() == 0 ? 1 : 0;
Identical, and simpler, to just write:
privileged = !geteuid();
ACK by code inspection, but I'd prefer actual build test before committing this. It qualifies for inclusion in 0.9.2 if we act fast enough, but I don't think it is a show-stopper if we miss out on Solaris builds for this release.
-- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
It builds, and starts, but nothing more than that: root@openindiana:~# virsh list error: Failed to reconnect to the hypervisor error: no valid connection error: no connection driver available for No connection for URI (null) But hey, it's a start :-) Kind regards, Ruben
On Fri, 2011-06-03 at 09:11 +0200, Matthias Bolte wrote:
It has probably something to do with this piece of code, in daemon/libvirtd.c:
I finally got back to looking at this, and that's what I discovered as well. (I hadn't checked my email in the interim.) I stopped it from dropping privileges and now libvirtd starts. Earlier, when launching virsh (with no arguments), I think I got some errors about localhost:8000. I ignored that, as I'm really looking to test VirtualBox, which brings me to this... If I don't have the VirtualBox GUI running, virsh fails to connect: /usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor I expected libvirt to handle starting VirtualBox processes as necessary. How is this designed to work? Thanks, Richard
On Fri, Jun 3, 2011 at 18:07, Richard Laager <rlaager@wiktel.com> wrote:
On Fri, 2011-06-03 at 09:11 +0200, Matthias Bolte wrote:
It has probably something to do with this piece of code, in daemon/libvirtd.c:
I finally got back to looking at this, and that's what I discovered as well. (I hadn't checked my email in the interim.)
I stopped it from dropping privileges and now libvirtd starts. Earlier, when launching virsh (with no arguments), I think I got some errors about localhost:8000.
I ignored that, as I'm really looking to test VirtualBox, which brings me to this...
If I don't have the VirtualBox GUI running, virsh fails to connect:
/usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor
Same issue here, on OpenIndiana.
I expected libvirt to handle starting VirtualBox processes as necessary.
It does.
How is this designed to work?
Without the GUI running: ruben@osx ~]$ virsh -c vbox:///session start OpenIndiana Domain OpenIndiana started I expect it's a Solaris issue. Cheers, Ruben
2011/6/3 Richard Laager <rlaager@wiktel.com>:
On Fri, 2011-06-03 at 09:11 +0200, Matthias Bolte wrote:
It has probably something to do with this piece of code, in daemon/libvirtd.c:
I finally got back to looking at this, and that's what I discovered as well. (I hadn't checked my email in the interim.)
I stopped it from dropping privileges and now libvirtd starts. Earlier, when launching virsh (with no arguments), I think I got some errors about localhost:8000.
I ignored that, as I'm really looking to test VirtualBox, which brings me to this...
If I don't have the VirtualBox GUI running, virsh fails to connect:
/usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor
This is typically a sign of a COM object ID mismatch between VirtualBox and libvirt. What versions of libvirt and VirtualBox are you running? By any chance are you running a beta or release candidate of VirtualBox?
I expected libvirt to handle starting VirtualBox processes as necessary. How is this designed to work?
You just have VirtualBox installed and it should work. Matthias
On Fri, Jun 3, 2011 at 21:07, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/6/3 Richard Laager <rlaager@wiktel.com>:
On Fri, 2011-06-03 at 09:11 +0200, Matthias Bolte wrote:
It has probably something to do with this piece of code, in daemon/libvirtd.c:
I finally got back to looking at this, and that's what I discovered as well. (I hadn't checked my email in the interim.)
I stopped it from dropping privileges and now libvirtd starts. Earlier, when launching virsh (with no arguments), I think I got some errors about localhost:8000.
I ignored that, as I'm really looking to test VirtualBox, which brings me to this...
If I don't have the VirtualBox GUI running, virsh fails to connect:
/usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor
This is typically a sign of a COM object ID mismatch between VirtualBox and libvirt. What versions of libvirt and VirtualBox are you running? By any chance are you running a beta or release candidate of VirtualBox?
libvirt-0.9.2-rc2, and VirtualBox-4.0.8-SunOS-r71778.pkg from www.virtualbox.org This exact same combination works fine on OSX.
On Fri, 2011-06-03 at 22:06 +0200, Ruben Kerkhof wrote:
If I don't have the VirtualBox GUI running, virsh fails to connect:
/usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor
This is typically a sign of a COM object ID mismatch between VirtualBox and libvirt. What versions of libvirt and VirtualBox are you running? By any chance are you running a beta or release candidate of VirtualBox?
libvirt-0.9.2-rc2, and VirtualBox-4.0.8-SunOS-r71778.pkg from www.virtualbox.org
I'm running libvirt-0.9.1 and the same VirtualBox (VirtualBox-4.0.8-SunOS-r71778.pkg). Richard
2011/6/4 Richard Laager <rlaager@wiktel.com>:
On Fri, 2011-06-03 at 22:06 +0200, Ruben Kerkhof wrote:
If I don't have the VirtualBox GUI running, virsh fails to connect:
/usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor
This is typically a sign of a COM object ID mismatch between VirtualBox and libvirt. What versions of libvirt and VirtualBox are you running? By any chance are you running a beta or release candidate of VirtualBox?
libvirt-0.9.2-rc2, and VirtualBox-4.0.8-SunOS-r71778.pkg from www.virtualbox.org
I'm running libvirt-0.9.1 and the same VirtualBox (VirtualBox-4.0.8-SunOS-r71778.pkg).
Richard
Okay VirtualBox 4.0.8 work with libvirt on Windows too. So this seems to be a Solaris specific problem. Does an earlier version of VirtualBox work, for example 4.0.0 or 3.2.10, or did it never work? Matthias
2011/6/4 Matthias Bolte <matthias.bolte@googlemail.com>:
2011/6/4 Richard Laager <rlaager@wiktel.com>:
On Fri, 2011-06-03 at 22:06 +0200, Ruben Kerkhof wrote:
If I don't have the VirtualBox GUI running, virsh fails to connect:
/usr/local/bin/virsh -c vbox:///session ... hangs for 10 or so seconds ... error: internal error nsIEventQueue object is null error: failed to connect to the hypervisor
This is typically a sign of a COM object ID mismatch between VirtualBox and libvirt. What versions of libvirt and VirtualBox are you running? By any chance are you running a beta or release candidate of VirtualBox?
libvirt-0.9.2-rc2, and VirtualBox-4.0.8-SunOS-r71778.pkg from www.virtualbox.org
I'm running libvirt-0.9.1 and the same VirtualBox (VirtualBox-4.0.8-SunOS-r71778.pkg).
Richard
Okay VirtualBox 4.0.8 work with libvirt on Windows too. So this seems to be a Solaris specific problem. Does an earlier version of VirtualBox work, for example 4.0.0 or 3.2.10, or did it never work?
Matthias
I was just testing libvirt with different VirtualBox versions on Windows and found a strange problem. After downgrading to VirtualBox 3.0.0 libvirt failed to connect with a strange error, about not being able to create the main IVirtualBox COM object. Using the VirtualBox GUI to create a dummy virtual machine fixed this, I've no clue why. Is the VirtualBox setup on your Solaris machine a fresh one or does it already have running virtual machines? Yes, this is a random guess into the blue :) Matthias
On Sat, Jun 4, 2011 at 10:40, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
Okay VirtualBox 4.0.8 work with libvirt on Windows too. So this seems to be a Solaris specific problem. Does an earlier version of VirtualBox work, for example 4.0.0 or 3.2.10, or did it never work?
I just tried 4.0.0, same behaviour. 3.2.12 does: ruben@openindiana:~$ virsh list VBoxSVC: error: 0 bytes read from child process error: Failed to reconnect to the hypervisor error: no valid connection error: internal error nsIEventQueue object is null This is with no running vms, only one which is stopped. I could have a look with gdb, if you can tell me which function I have to set a breakpoint on. Thanks! Ruben
2011/6/4 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Sat, Jun 4, 2011 at 10:40, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
Okay VirtualBox 4.0.8 work with libvirt on Windows too. So this seems to be a Solaris specific problem. Does an earlier version of VirtualBox work, for example 4.0.0 or 3.2.10, or did it never work?
I just tried 4.0.0, same behaviour. 3.2.12 does:
ruben@openindiana:~$ virsh list VBoxSVC: error: 0 bytes read from child process error: Failed to reconnect to the hypervisor error: no valid connection error: internal error nsIEventQueue object is null
This is with no running vms, only one which is stopped. I could have a look with gdb, if you can tell me which function I have to set a breakpoint on.
Thanks!
Ruben
Try running with full debug and logging LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr virsh list and post the output here. I want to verify that the rest is okay and the problem is there where I expect it. What the VirtualBox driver does is dlopen the VBoxXPCOMC.so, get the entry function VBoxGetXPCOMCFunctions and call it, see tryLoadOne in src/vbox/vbox_XPCOMGlue.c. This seems to work otherwise it wouldn't have gotten to the nsIEventQueue error. Then in src/vbox/vbox_tmp.c in vboxInitialize pfnComInitialize is called to initialize the XPCOM interface and get the IVirtualBox and ISession objects. After that it tries to obtain the IEventQueue object and fails because it's NULL. The error reporting order in this function is suboptimal and I'll fix that. Actually it should check the IVirtualBox and ISession object for NULL first because the call to pfnComInitialize probably already failed. But the signature of pfnComInitialize is bad, it should return a value to indicate an error. You also can't tell what the actual problem is because pfnComInitialize internally logs the reason but logging is typically compiled out. pfnComInitialize points to VBoxComInitialize in src/VBox/Main/cbindings/VBoxXPCOMC.cpp in the VirtualBox source code. Last time I debugged such a problem I ended up compiling VBoxXPCOMC.so from source and replace the system VBoxXPCOMC.so with my own one that just wrote debug messages to a file in /tmp so that I could figure out the actual problem. Last time it was a mismatch in the COM object IDs for the IVirtualBox and ISession objects. libvirt accidentally used the IDs from a beta VirtualBox SDK and the IDs had changed in the actual release. This made the CreateInstanceByContractID calls in VBoxComInitialize fail, and VBoxComUninitialize is called that releases the IEventQueue object and it's NULL when the VirtualBox driver checks it later. So the error message about IEventQueue being NULL is just a symptom of VBoxComInitialize failing. If we want to fix this we need to figure out why VBoxComInitialize fails. You could try to break on VBoxComInitialize in VBoxXPCOMC.so in gdb. You could also try to make gdb step into the call to VBoxComInitialize in vboxInitialize via pfnComInitialize. I fail at this, maybe it's not even possible. As said last time I compiled my own VBoxXPCOMC.so with debug log output in it to figure out the problem. Matthias
On Sat, Jun 4, 2011 at 16:37, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/6/4 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Sat, Jun 4, 2011 at 10:40, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
Okay VirtualBox 4.0.8 work with libvirt on Windows too. So this seems to be a Solaris specific problem. Does an earlier version of VirtualBox work, for example 4.0.0 or 3.2.10, or did it never work?
I just tried 4.0.0, same behaviour. 3.2.12 does:
ruben@openindiana:~$ virsh list VBoxSVC: error: 0 bytes read from child process error: Failed to reconnect to the hypervisor error: no valid connection error: internal error nsIEventQueue object is null
This is with no running vms, only one which is stopped. I could have a look with gdb, if you can tell me which function I have to set a breakpoint on.
Thanks!
Ruben
Try running with full debug and logging
LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr virsh list
and post the output here. I want to verify that the rest is okay and the problem is there where I expect it.
Ok, here it is: ruben@openindiana:~$ LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr virsh list 16:57:26.268: 1: info : libvirt version: 0.9.2 16:57:26.268: 1: debug : virInitialize:395 : register drivers 16:57:26.270: 1: debug : virRegisterDriver:750 : driver=fef04f20 name=Test 16:57:26.271: 1: debug : virRegisterDriver:774 : registering Test as driver 0 16:57:26.271: 1: debug : virRegisterNetworkDriver:567 : registering Test as network driver 0 16:57:26.272: 1: debug : virRegisterInterfaceDriver:600 : registering Test as interface driver 0 16:57:26.272: 1: debug : virRegisterStorageDriver:633 : registering Test as storage driver 0 16:57:26.272: 1: debug : virRegisterDeviceMonitor:666 : registering Test as device driver 0 16:57:26.273: 1: debug : virRegisterSecretDriver:699 : registering Test as secret driver 0 16:57:26.273: 1: debug : virRegisterNWFilterDriver:732 : registering Test as network filter driver 0 16:57:26.274: 1: debug : virRegisterDriver:750 : driver=fef051c0 name=Xen 16:57:26.274: 1: debug : virRegisterDriver:774 : registering Xen as driver 1 16:57:26.275: 1: debug : virRegisterDriver:750 : driver=fef00ee0 name=VMWARE 16:57:26.275: 1: debug : virRegisterDriver:774 : registering VMWARE as driver 2 16:57:26.328: 1: debug : tryLoadOne:163 : Found VBoxXPCOMC.so in '/opt/VirtualBox/i386' 16:57:26.329: 1: debug : vboxRegister:94 : VBoxCGlueInit found API version: 3.2.12 (3002012) 16:57:26.329: 1: debug : vboxRegister:116 : VirtualBox API version: 3.2 16:57:26.330: 1: debug : virRegisterDriver:750 : driver=fef05ba0 name=VBOX 16:57:26.331: 1: debug : virRegisterDriver:774 : registering VBOX as driver 3 16:57:26.332: 1: debug : virRegisterNetworkDriver:567 : registering VBOX as network driver 1 16:57:26.332: 1: debug : virRegisterStorageDriver:633 : registering VBOX as storage driver 1 16:57:26.333: 1: debug : virRegisterDriver:750 : driver=fef01820 name=ESX 16:57:26.334: 1: debug : virRegisterDriver:774 : registering ESX as driver 4 16:57:26.334: 1: debug : virRegisterInterfaceDriver:600 : registering ESX as interface driver 1 16:57:26.335: 1: debug : virRegisterNetworkDriver:567 : registering ESX as network driver 2 16:57:26.336: 1: debug : virRegisterStorageDriver:633 : registering ESX as storage driver 2 16:57:26.336: 1: debug : virRegisterDeviceMonitor:666 : registering ESX as device driver 1 16:57:26.336: 1: debug : virRegisterSecretDriver:699 : registering ESX as secret driver 1 16:57:26.337: 1: debug : virRegisterNWFilterDriver:732 : registering ESX as network filter driver 1 16:57:26.337: 1: debug : virRegisterDriver:750 : driver=fef00ca0 name=remote 16:57:26.338: 1: debug : virRegisterDriver:774 : registering remote as driver 5 16:57:26.338: 1: debug : virRegisterNetworkDriver:567 : registering remote as network driver 3 16:57:26.339: 1: debug : virRegisterInterfaceDriver:600 : registering remote as interface driver 2 16:57:26.339: 1: debug : virRegisterStorageDriver:633 : registering remote as storage driver 3 16:57:26.340: 1: debug : virRegisterDeviceMonitor:666 : registering remote as device driver 2 16:57:26.340: 1: debug : virRegisterSecretDriver:699 : registering remote as secret driver 2 16:57:26.341: 1: debug : virRegisterNWFilterDriver:732 : registering remote as network filter driver 2 16:57:26.343: 1: debug : virEventRegisterDefaultImpl:148 : registering default event implementation 16:57:26.344: 1: debug : virEventPollAddHandle:111 : Add handle fd=3 events=1 cb=fec5a5c0 opaque=0 16:57:26.344: 1: debug : virEventPollAddHandle:115 : Used 0 handle slots, adding at least 10 more 16:57:26.345: 1: debug : virEventPollInterruptLocked:686 : Skip interrupt, 0 0 16:57:26.345: 1: debug : virEventRegisterImpl:121 : addHandle=fec5ace0 updateHandle=fec5ac00 removeHandle=fec5aae0 addTimeout=fec5a904 updateTimeout=fec5a7b0 removeTimeout=fec5a6c8 16:57:26.346: 1: debug : virConnectOpenAuth:1327 : name=(null), auth=fef00784, flags=0 16:57:26.349: 1: debug : do_open:1064 : no name, allowing driver auto-select 16:57:26.349: 1: debug : do_open:1101 : trying driver 0 (Test) ... 16:57:26.352: 1: debug : do_open:1107 : driver 0 Test returned DECLINED 16:57:26.352: 1: debug : do_open:1101 : trying driver 1 (Xen) ... 16:57:26.352: 1: debug : do_open:1107 : driver 1 Xen returned DECLINED 16:57:26.352: 1: debug : do_open:1101 : trying driver 2 (VMWARE) ... 16:57:26.356: 1: debug : do_open:1107 : driver 2 VMWARE returned DECLINED 16:57:26.356: 1: debug : do_open:1101 : trying driver 3 (VBOX) ... VBoxSVC: error: 0 bytes read from child process 16:57:57.714: 1: error : vboxInitialize:894 : internal error nsIEventQueue object is null 16:57:58.045: 1: debug : do_open:1107 : driver 3 VBOX returned ERROR 16:57:58.047: 1: debug : virUnrefConnect:145 : unref connection 80a5a18 1 16:57:58.047: 1: debug : virReleaseConnect:94 : release connection 80a5a18 error: Failed to reconnect to the hypervisor error: no valid connection error: internal error nsIEventQueue object is null
What the VirtualBox driver does is dlopen the VBoxXPCOMC.so, get the entry function VBoxGetXPCOMCFunctions and call it, see tryLoadOne in src/vbox/vbox_XPCOMGlue.c. This seems to work otherwise it wouldn't have gotten to the nsIEventQueue error. Then in src/vbox/vbox_tmp.c in vboxInitialize pfnComInitialize is called to initialize the XPCOM interface and get the IVirtualBox and ISession objects. After that it tries to obtain the IEventQueue object and fails because it's NULL. The error reporting order in this function is suboptimal and I'll fix that. Actually it should check the IVirtualBox and ISession object for NULL first because the call to pfnComInitialize probably already failed. But the signature of pfnComInitialize is bad, it should return a value to indicate an error. You also can't tell what the actual problem is because pfnComInitialize internally logs the reason but logging is typically compiled out.
pfnComInitialize points to VBoxComInitialize in src/VBox/Main/cbindings/VBoxXPCOMC.cpp in the VirtualBox source code. Last time I debugged such a problem I ended up compiling VBoxXPCOMC.so from source and replace the system VBoxXPCOMC.so with my own one that just wrote debug messages to a file in /tmp so that I could figure out the actual problem. Last time it was a mismatch in the COM object IDs for the IVirtualBox and ISession objects. libvirt accidentally used the IDs from a beta VirtualBox SDK and the IDs had changed in the actual release. This made the CreateInstanceByContractID calls in VBoxComInitialize fail, and VBoxComUninitialize is called that releases the IEventQueue object and it's NULL when the VirtualBox driver checks it later. So the error message about IEventQueue being NULL is just a symptom of VBoxComInitialize failing.
If we want to fix this we need to figure out why VBoxComInitialize fails. You could try to break on VBoxComInitialize in VBoxXPCOMC.so in gdb. You could also try to make gdb step into the call to VBoxComInitialize in vboxInitialize via pfnComInitialize. I fail at this, maybe it's not even possible.
You're right, I'm not able to step into any VBoxXPCOMC functions: Breakpoint 1, vboxOpen (conn=0x80a5a18, auth=0xfef00784, flags=0) at vbox/vbox_tmpl.c:878 878 data->pFuncs->pfnComInitialize(IVIRTUALBOX_IID_STR, &data->vboxObj, (gdb) s [New LWP 1] [New LWP 2] [New LWP 3] 890 data->pFuncs->pfnGetEventQueue(&data->vboxQueue);
As said last time I compiled my own VBoxXPCOMC.so with debug log output in it to figure out the problem.
Matthias
Ok, I'll look into doing the same. Thanks, Ruben
On Sat, Jun 4, 2011 at 17:20, Ruben Kerkhof <ruben@rubenkerkhof.com> wrote:
On Sat, Jun 4, 2011 at 16:37, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
2011/6/4 Ruben Kerkhof <ruben@rubenkerkhof.com>:
On Sat, Jun 4, 2011 at 10:40, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
Okay VirtualBox 4.0.8 work with libvirt on Windows too. So this seems to be a Solaris specific problem. Does an earlier version of VirtualBox work, for example 4.0.0 or 3.2.10, or did it never work?
I'm starting to think this has something to do with the VBoxSVC and VBoxXPCOMID not running. The VBoxSVC process is normally started when you start the first vm. If I start it manually, virsh list works. Hope this helps, Ruben
On Fri, 2011-06-03 at 09:11 +0200, Matthias Bolte wrote:
That might be the problem. I don't have a Solaris at hand right now to test it so here is a speculative patch for this.
I tested this patch. I'll discuss that first and then recount the problems I experienced along the way. The patch seems to achieve the desired effect. libvirtd starts up as the user xvm. (That said, with Oracle dropping the xvm feature, I'm not sure if this is better than just running as root.) VirtualBox (and VBoxSVC) were crashing with "Memory fault", apparently because they couldn't create /.VirtualBox (xvm's ~ is /). Once I created that directory (and chown'ed/chgrp'ed it to xvm), I could start VBoxSVC. From there, virsh connects. It seems to intermittently have problems; I'm trying to reproduce that issue before I can go much further. For this testing, I thought it'd be good to use a git checkout, as we had previously discussed. I was hung up for a while because the gnulib git repository was down. Now it seems to be back up, so I'm trying again. Unfortunately, I'm having a number of build issues: 1) I only have gettext 0.16, so I made these changes: diff --git a/bootstrap.conf b/bootstrap.conf index 769e57c..5427c17 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -164,7 +164,7 @@ buildreq="\ autoconf 2.59 automake 1.9.6 autopoint - -gettext 0.17 +gettext 0.16 git 1.5.5 gzip - libtool - diff --git a/configure.ac b/configure.ac index 25669cf..c6346cc 100644 --- a/configure.ac +++ b/configure.ac @@ -2062,7 +2062,7 @@ dnl Enable building libvirtd? AM_CONDITIONAL([WITH_LIBVIRTD],[test "x$with_libvirtd" = "xyes"]) dnl Check for gettext - don't go any newer than what RHEL 5 supports -AM_GNU_GETTEXT_VERSION([0.17]) +AM_GNU_GETTEXT_VERSION([0.16]) AM_GNU_GETTEXT([external]) ALL_LINGUAS=`cd "$srcdir/po" > /dev/null && ls *.po | sed 's+\.po$++'` 2) The script isn't finding my automake and aclocal, even though they're installed. Solaris has those executables named with a version number. I'm not experienced enough with Solaris to know if there's any standard way via the package manger to make one available as just plain automake (similar to Debian's alternatives system). So I just did this: ACLOCAL=aclocal-1.9 AUTOMAKE=automake-1.9 ./autogen.sh 3) The bootstrap script previously (when I had manually copied in a gnulib git checkout from a month-or-so-old libvirt checkout on Linux) was complaining that rpcgen didn't exist. I've never heard of that program, but I apparently have something by that name installed: # rpcgen rpcgen (1.1) usage: rpcgen infile rpcgen [-abCLNTMA] [-Dname[=value]] [-i size] [-I [-K seconds]] [-Y path] infile rpcgen [-c | -h | -l | -m | -t | -Sc | -Ss | -Sm] [-o outfile] [infile] rpcgen [-s nettype]* [-o outfile] [infile] rpcgen [-n netid]* [-o outfile] [infile] options: -a generate all files, including samples -A generate code to enable automatic MT mode -b backward compatibility mode (generates code for SunOS 4.X) -c generate XDR routines -C ANSI C mode -Dname[=value] define a symbol (same as #define) -h generate header file -i size size at which to start generating inline code -I generate code for inetd support in server (for SunOS 4.X) -K seconds server exits after K seconds of inactivity -l generate client side stubs -L server errors will be printed to syslog -m generate server side stubs -M generate MT-safe code -n netid generate server code that supports named netid -N supports multiple arguments and call-by-value -o outfile name of the output file -s nettype generate server code that supports named nettype -Sc generate sample client code that uses remote procedures -Ss generate sample server code that defines remote procedures -Sm generate makefile template -t generate RPC dispatch table -T generate code to support RPC dispatch tables -v print version information and exit -Y path path where cpp is found 4) The bootstrap script (well, really autopoint) failed because cvs is not installed: ./bootstrap: cp ._bootmp/gnulib/lib/glthread/threadlib.c gnulib/lib/glthread/threadlib.c # with edits ./bootstrap: (cd ._bootmp2; autopoint) ... autopoint: *** cvs program not found autopoint: *** Stop. Failed to bootstrap, please investigate. Why on earth does it want cvs? Is that really used? I installed it so I could move on. 5) pod2man is not in the PATH on Solaris. This patch detects it: diff --git a/configure.ac b/configure.ac index 25669cf..e6d31fa 100644 --- a/configure.ac +++ b/configure.ac @@ -153,6 +153,8 @@ AC_PATH_PROG([XMLLINT], [xmllint], [/usr/bin/xmllint]) AC_PATH_PROG([XMLCATALOG], [xmlcatalog], [/usr/bin/xmlcatalog]) AC_PATH_PROG([XSLTPROC], [xsltproc], [/usr/bin/xsltproc]) AC_PATH_PROG([AUGPARSE], [augparse], [/usr/bin/augparse]) +AC_PATH_PROG([POD2MAN], [pod2man], [/usr/bin/pod2man], [$PATH$PATH_SEPARATOR/usr/perl5/bin]) +AC_SUBST([POD2MAN]) AC_PROG_MKDIR_P dnl External programs that we can use if they are available. diff --git a/daemon/Makefile.am b/daemon/Makefile.am index c1b4a9f..0e80f46 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -349,8 +349,7 @@ endif # WITH_LIBVIRTD # This is needed for 'make dist' too, so can't wrap in WITH_LIBVIRTD. EXTRA_DIST += probes.d libvirtd.stp -POD2MAN = pod2man -c "Virtualization Support" \ - -r "$(PACKAGE)-$(VERSION)" -s 8 +POD2MAN += -c "Virtualization Support" -r "$(PACKAGE)-$(VERSION)" -s 8 $(srcdir)/libvirtd.8.in: libvirtd.pod.in $(AM_V_GEN)$(POD2MAN) $< $@ diff --git a/tools/Makefile.am b/tools/Makefile.am index 826674a..77d8b10 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -1,5 +1,5 @@ -POD2MAN = pod2man -c "Virtualization Support" -r "$(PACKAGE)-$(VERSION)" +POD2MAN += -c "Virtualization Support" -r "$(PACKAGE)-$(VERSION)" ICON_FILES = \ libvirt_win_icon_16x16.ico \ 6) I still had the issue with the version script code. Here's the error output: creating libvirt.la (cd .libs && rm -f libvirt.la && ln -s ../libvirt.la libvirt.la) if /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../src/util -I../include -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wdisabled-optimization -Wpacked-bitfield-compat -Wmultichar -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -funit-at-a-time -DIN_LIBVIRT -D_REENTRANT -D_REENTRANT -g -O2 -MT libvirt_qemu_la-libvirt-qemu.lo -MD -MP -MF ".deps/libvirt_qemu_la-libvirt-qemu.Tpo" -c -o libvirt_qemu_la-libvirt-qemu.lo `test -f 'libvirt-qemu.c' || echo './'`libvirt-qemu.c; \ then mv -f ".deps/libvirt_qemu_la-libvirt-qemu.Tpo" ".deps/libvirt_qemu_la-libvirt-qemu.Plo"; else rm -f ".deps/libvirt_qemu_la-libvirt-qemu.Tpo"; exit 1; fi gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../src/util -I../include -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wdisabled-optimization -Wpacked-bitfield-compat -Wmultichar -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -funit-at-a-time -DIN_LIBVIRT -D_REENTRANT -D_REENTRANT -g -O2 -MT libvirt_qemu_la-libvirt-qemu.lo -MD -MP -MF .deps/libvirt_qemu_la-libvirt-qemu.Tpo -c libvirt-qemu.c -fPIC -DPIC -o .libs/libvirt_qemu_la-libvirt-qemu.o gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../src/util -I../include -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wdisabled-optimization -Wpacked-bitfield-compat -Wmultichar -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -funit-at-a-time -DIN_LIBVIRT -D_REENTRANT -D_REENTRANT -g -O2 -MT libvirt_qemu_la-libvirt-qemu.lo -MD -MP -MF .deps/libvirt_qemu_la-libvirt-qemu.Tpo -c libvirt-qemu.c -o libvirt_qemu_la-libvirt-qemu.o >/dev/null 2>&1 /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -o libvirt-qemu.la -rpath /usr/local/lib -Wl,-M -Wl,./libvirt_qemu.syms -version-info 9:1:9 libvirt_qemu_la-libvirt-qemu.lo libvirt.la -lnsl -lintl rm -fr .libs/libvirt-qemu.a .libs/libvirt-qemu.la .libs/libvirt-qemu.lai .libs/libvirt-qemu.so .libs/libvirt-qemu.so.0 .libs/libvirt-qemu.so.0.9.1 .libs/libvirt-qemu.so.0.9.1T gcc -std=gnu99 -shared -Wl,-h -Wl,libvirt-qemu.so.0 -o .libs/libvirt-qemu.so.0.9.1 .libs/libvirt_qemu_la-libvirt-qemu.o -R/home/dtb/libvirt/src/.libs -R/usr/local/lib ./.libs/libvirt.so -lnsl -lintl -lc -Wl,-M -Wl,./libvirt_qemu.syms Undefined first referenced symbol in file _fini /usr/lib/crti.o (symbol has no version assigned) _init /usr/lib/crti.o (symbol has no version assigned) __dso_handle /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/crtbegin.o (symbol has no version assigned) _lib_version /usr/lib/values-Xa.o (symbol has no version assigned) ld: fatal: symbol referencing errors. No output written to .libs/libvirt-qemu.so.0.9.1 collect2: ld returned 1 exit status make[3]: *** [libvirt-qemu.la] Error 1 As I mentioned before, this change "fixes" the problem: VERSION_SCRIPT_FLAGS=-Wl,--version-script= `$LD --help 2>&1 | grep -- --version-script >/dev/null` || \ - VERSION_SCRIPT_FLAGS="-Wl,-M -Wl," + VERSION_SCRIPT_FLAGS="" The more I look into this, though, the less I think that's correct. But I don't know enough about symbol versioning, especially under Solaris, to figure out the correct fix. ======= BACK ON LINUX: Since I was having so much trouble building from a git clone of libvirt on Solaris 11 Express, I decided to do the git checkout on my Linux machine and run `make dist` there. Unfortunately, make dist failed on Linux (Ubuntu Natty): GEN libvirt-api.xml Rebuilding API description for libvirt Parsing ./../include/libvirt/virterror.h Parsing ./../include/libvirt/libvirt.h Parsing ./../src/util/event.c Parsing ./../src/util/virterror.c Parsing ./../src/libvirt.c Project libvirt : 2 headers, 3 modules 307 public functions 1 public variables 19 public structs 119 public typedefs 27 public macros Saving XML description ./libvirt-api.xml Saving XML Cross References ./libvirt-refs.xml Rebuilding the HTML pages from the XML API missing XHTML1 DTD Rebuilding devhelp files cp: cannot stat `./api.html': No such file or directory make[1]: *** [distdir] Error 1 As always, I welcome any thoughts or feedback. Richard
On Sat, 2011-06-04 at 21:57 -0500, Richard Laager wrote:
From there, virsh connects. It seems to intermittently have problems; I'm trying to reproduce that issue before I can go much further.
As the user xvm: This works: /usr/local/bin/virsh -c vbox:///session list This doesn't: /usr/local/bin/virsh -c vbox+ssh://localhost/session list The latter does create an SSH connection, as it asks me for my password. Also, before I had netcat installed, I got an error about nc not existing. Any ideas? Richard
On Sun, Jun 5, 2011 at 05:17, Richard Laager <rlaager@wiktel.com> wrote:
On Sat, 2011-06-04 at 21:57 -0500, Richard Laager wrote:
From there, virsh connects. It seems to intermittently have problems; I'm trying to reproduce that issue before I can go much further.
As the user xvm: This works: /usr/local/bin/virsh -c vbox:///session list This doesn't: /usr/local/bin/virsh -c vbox+ssh://localhost/session list
The latter does create an SSH connection, as it asks me for my password. Also, before I had netcat installed, I got an error about nc not existing.
Any ideas?
What happens if you run libvirtd as root, and virsh list as yourself?
Hi Matthias, On Sun, May 29, 2011 at 12:34, Matthias Bolte <matthias.bolte@googlemail.com> wrote:
That's strange, configure should automatically disable the Xen driver if it can't find the required headers and libs. The only way I can see from the logic in configure is that configure found libxenstore but can't find the headers such as xen/xen.h xen/version.h xen/dom0_ops.h xen/sys/privcmd.h xen/linux/privcmd.h.
I think you're right. In my default OpenIndiana b151 install, /usr/lib/xenstore.so exists (from the xvmstore package), but not the xvm headers. They're in the xvm-headers package. I assume it's the same on Solaris Express 11. Kind regards, Ruben
On Thu, 2011-06-02 at 17:33 +0200, Ruben Kerkhof wrote:
In my default OpenIndiana b151 install, /usr/lib/xenstore.so exists (from the xvmstore package), but not the xvm headers. They're in the xvm-headers package.
Do you actually have Xen running or know much about the Xen on Solaris situation? From what I've been able to find searching the web, it seems that some recentish (before it died) version of OpenSolaris and thus Solaris 11 has removed support for running as a Xen dom0. It seems that at one point, Solaris did exactly what I wanted (virtualization using ZFS for storage and libvirt for management): http://dlc.sun.com/osol/docs/content/SYSADRM/gentextid-22771.html Richard
participants (4)
-
Eric Blake -
Matthias Bolte -
Richard Laager -
Ruben Kerkhof