Andreas Höschler schrieb:
Hi Klaus,
It's certainly not a port conflict as such, as VirtualBox
uses unix domain sockets (in /tmp/.vbox-USERNAME-ipc/). It
sounds more like VBoxSVC or VBoxXPCOMIPCD got wedged, and
that causes the client apps (VirtualBox, VBoxHeadless,
VBoxManage ...) to hang as well. However if you terminate
everything that should clear the problem.
Thanks for the feedback. It helped the last time, but not now! :-(
The headless instances still run, but they cannot be restarted
and the VirtualBox control application simply does not come up.
I wonder whether I am the only one with this problem! :-(
I don't follow... the entire VirtualBox infrastructure is dead once
you kill VBoxSVC. VBoxHeadless instances may continue to run for
some time, but usually they abort pretty quickly. If they don't,
they nevertheless keep the local domain socket open and thus can
potentially cause trouble.
I'm pretty sure that there are not that many people out there who
are haunted by such massive VBoxSVC problems. The number of reports
in that direction is pretty close to zero, and that means your
problem is special. Maybe you could enable core dumps, to see
whether the real cause is actually a VBoxSVC crash before you get
into this odd state.
I looked further into this issue. No app or tool seems to crash, so no
core dump. The vbox infrastruture simply starts to hang (headless
instances continue to run and are still operable but no additional
instances can be started nor the VirtualBox control application) very
soon after firing it up. It also has nothing to do with shutting down
any machines. After rebooting the machine VirtualBox control app works
fine. I fire up a few instances with VBoxHeadless. A couple of hours
later I try to start another Headless instance or try to restart
VirtualBox control app and it no longer works! :-(
Seems someone needs to dig into the state of VBoxSVC once it's
non-operational. You could create a core dump with "gcore", and give it
to us for analysis.
We haven't had this issue with 2.0.6 and we don't have this issue with
3.0.6 on another machine. However, 3.0.6 unfortunately still has a bug
that crashes the whole physical machine under certain circumstances
(just reproduced that a couple of times; very annoying especailly since
the service processor seems to have a malfunction as well and does not
allow to remotely reset the machine! :-()! So downgrading to 3.0.6 is no
option. I am wondering whether this hang bug was already introduced in
3.1.0 and whether the system crash bug is already fixed in 3.1.0!?
We encounter the mentioned problems on a X4240 (Solaris 10). Anybody
else running vbox on Solaris and encountering similar problems?
There are quite a number of customers, who e.g. use Sun VDI. Haven't
heard of serious stability problems in that context for a while. Though
that product is based on VirtualBox 3.0.12 right now (VDI 3.1).
3.0.6 is quite old. And 3.1.0 has been superseded by 3.1.2 more than a
month ago, and that fixes a number of bugs and regressions...
VirtualBox on Solaris is a pretty cool virtualization tool. Once all
these little oddities (system crash under certain circumstance, vbox
infra structure hangs, USB device mapping,..) are fixed we will be
really happy campers! :-)
Better don't hold your breath with USB device mapping. It works quite
nicely with OpenSolaris b126+, however I'm not aware of plans to
integrate the required kernel bits into Solaris 10.
Klaus
_______________________________________________
vbox-users mailing list
vbox-users@virtualbox.org
http://vbox.innotek.de/mailman/listinfo/vbox-users
