9:01 p.m.
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
'(a)//.libvirt/libvirt-sock': No such file or directory
Thanks,
Richard
5:34 a.m.
2011/5/29 Richard Laager <rlaager(a)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
'(a)//.libvirt/libvirt-sock': No such file or directory
'(a)//.libvirt/libvirt-sock' should actually look like this
'(a)/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
12:35 p.m.
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.
'(a)//.libvirt/libvirt-sock' should actually look like this
'(a)/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
12:45 p.m.
2011/5/29 Richard Laager <rlaager(a)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.
> '(a)//.libvirt/libvirt-sock' should actually look like this
> '(a)/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
5:18 p.m.
On Sun, May 29, 2011 at 19:45, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
2011/5/29 Richard Laager <rlaager(a)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.
>
>> '(a)//.libvirt/libvirt-sock' should actually look like this
>> '(a)/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
1:52 a.m.
2011/5/30 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
On Sun, May 29, 2011 at 19:45, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
> 2011/5/29 Richard Laager <rlaager(a)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.
>>
>>> '(a)//.libvirt/libvirt-sock' should actually look like this
>>> '(a)/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
7:21 p.m.
On Mon, May 30, 2011 at 08:52, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
2011/5/30 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
> On Sun, May 29, 2011 at 19:45, Matthias Bolte
> <matthias.bolte(a)googlemail.com> wrote:
>> 2011/5/29 Richard Laager <rlaager(a)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.
>>>
>>>> '(a)//.libvirt/libvirt-sock' should actually look like this
>>>> '(a)/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
2:11 a.m.
2011/6/3 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
On Mon, May 30, 2011 at 08:52, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
> 2011/5/30 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
>> On Sun, May 29, 2011 at 19:45, Matthias Bolte
>> <matthias.bolte(a)googlemail.com> wrote:
>>> 2011/5/29 Richard Laager <rlaager(a)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.
>>>>
>>>>> '(a)//.libvirt/libvirt-sock' should actually look like this
>>>>> '(a)/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
9:16 a.m.
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
10:30 a.m.
On Fri, Jun 3, 2011 at 16:16, Eric Blake <eblake(a)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(a)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
11:07 a.m.
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
12:50 p.m.
On Fri, Jun 3, 2011 at 18:07, Richard Laager <rlaager(a)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
2:07 p.m.
2011/6/3 Richard Laager <rlaager(a)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
3:06 p.m.
On Fri, Jun 3, 2011 at 21:07, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
2011/6/3 Richard Laager <rlaager(a)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.
5:43 p.m.
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
3:40 a.m.
2011/6/4 Richard Laager <rlaager(a)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
3:53 a.m.
2011/6/4 Matthias Bolte <matthias.bolte(a)googlemail.com>:
2011/6/4 Richard Laager <rlaager(a)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
8:25 a.m.
On Sat, Jun 4, 2011 at 10:40, Matthias Bolte
<matthias.bolte(a)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
9:37 a.m.
2011/6/4 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
On Sat, Jun 4, 2011 at 10:40, Matthias Bolte
<matthias.bolte(a)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
10:20 a.m.
On Sat, Jun 4, 2011 at 16:37, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
2011/6/4 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
> On Sat, Jun 4, 2011 at 10:40, Matthias Bolte
> <matthias.bolte(a)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
12:37 p.m.
On Sat, Jun 4, 2011 at 17:20, Ruben Kerkhof <ruben(a)rubenkerkhof.com> wrote:
On Sat, Jun 4, 2011 at 16:37, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
> 2011/6/4 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
>> On Sat, Jun 4, 2011 at 10:40, Matthias Bolte
>> <matthias.bolte(a)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
9:57 p.m.
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
10:17 p.m.
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
7:17 a.m.
On Sun, Jun 5, 2011 at 05:17, Richard Laager <rlaager(a)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?
10:33 a.m.
Hi Matthias,
On Sun, May 29, 2011 at 12:34, Matthias Bolte
<matthias.bolte(a)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
11:07 a.m.
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
4919
days inactive
4926
days old
25 comments
4 participants
participants (4)
-
Eric Blake -
Matthias Bolte -
Richard Laager -
Ruben Kerkhof