Problem with guest additions services in openSUSE 13.1

English Virtualization
1

I’ve installed openSUSE 13.1 from the (KDE) live CD as a guest in a VirtualBox VM. The host is also openSUSE 13.1 and both the host VirtualBox and the guest additions are the standard openSUSE issue - the ones installed by default. I reckon this must be about the simplest arrangement to get going…

But I’m having problems. As far as I can see, the guest additions services aren’t running completely. There are 4 different instances of /usr/bin/VBoxClient running on the guest (each with different parameters) and some guest services are working (keyboard/mouse integration, cut & paste, scaling & seamless mode, shared folders). However, there’s no instance of /usr/bin/VBoxService running, so there’s no time synchronisation and no guest control (e.g. running commands on the guest from the host).

Now I don’t know if this is the intended default arrangement or not. If I run VBoxService (as root in the guest), these additional services start working OK, but I’m a bit surprised that I need to do that.

What makes me think here’s a problem is that if I look at the vmtoolsd system service (in yast) there are errors, like the following:

vmtoolsd.service - LSB: VMWare Tools Daemon
   Loaded: loaded (/etc/init.d/vmtoolsd)
   Active: failed (Result: exit-code) since Mon 2014-06-16 15:50:47 EDT; 7min ago
  Process: 531 ExecStart=/etc/init.d/vmtoolsd start (code=exited, status=7)
   CGroup: /system.slice/vmtoolsd.service
           `-562 /usr/bin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse

Jun 16 15:50:41 linux-6c9d systemd[1]: Starting LSB: VMWare Tools Daemon...
Jun 16 15:50:44 linux-6c9d vmtoolsd[531]: Starting vmtoolsd FATAL: Error inserting vmw_balloon (/lib/modules/3.11.10-11-desktop/kernel/drivers/misc/vmw_balloon.ko): No such device
Jun 16 15:50:44 linux-6c9d vmtoolsd[531]: FATAL: Module vmsync not found.
Jun 16 15:50:47 linux-6c9d vmsvc[604]:  warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-app-ctx after class was initialised
Jun 16 15:50:47 linux-6c9d vmsvc[604]:  warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-prop-thread-pool after class was initialised
Jun 16 15:50:47 linux-6c9d vmsvc[604]:  warning] [vmtoolsd] The vmsvc service needs to run inside a virtual machine.
Jun 16 15:50:47 linux-6c9d vmtoolsd[531]: ..failed
Jun 16 15:50:47 linux-6c9d systemd[1]: vmtoolsd.service: control process exited, code=exited status=7
Jun 16 15:50:47 linux-6c9d systemd[1]: Failed to start LSB: VMWare Tools Daemon.
Jun 16 15:50:47 linux-6c9d systemd[1]: Unit vmtoolsd.service entered failed state.

Trying to manually start this service also gives the same errors. So I’m wondering if the lack of a VBoxService instance is because things aren’t starting up as they should.

So I’d appreciate any help with this. Should VBoxService be running by default? If so, are the above errors likely to be responsible and what might be the problem?

Thanks.

2

[QUOTE=xanti;2650854What makes me think here’s a problem is that if I look at the vmtoolsd system service (in yast) there are errors, like the following:
…
Trying to manually start this service also gives the same errors. So I’m wondering if the lack of a VBoxService instance is because things aren’t starting up as they should.[/QUOTE]
The vmtoolsd.service is for VMware as the name implies, not VirtualBox.
So it’s obvious that you cannot start it.

So I’d appreciate any help with this. Should VBoxService be running by default? If so, are the above errors likely to be responsible and what might be the problem?

VBoxService itself is not running by default, that’s normal.

Apparently the guest additions are working, aren’t they?

I have no idea about the “time synchronisation and guest control (e.g. running commands on the guest from the host)” that you mention though.
So I take it that VBoxService must be running for those to work?

If you think it should be running by default, you should file a bug report:
http://bugzilla.novell.com/ (same username/password as here).

3

IMO, besides as wolfi noted that you can’t run a VMware service on a VirtualBox HostOS and get anything but an error,

  • You need to describe what you mean by “running commands on the guest from the host”
    If you mean running a command within a Guest from the Host, I doubt it is supported in VBox (or even VMware AFAIK). Personally, the only “virtualization” I’ve done this type of thing is when using LXC and that is because of the shared file system.
    If you mean you’re trying to manage Guests using a command line instead of using the GUI, then you need to describe the exact command which is failing. Any/all should work.

  • Any time you experience a problem, you have to be detailed about what you attempted to configure and what your result was. From your post, I have no idea if you even tried to set time sync correctly as follows (modify as needed for your system)

vboxmanage setextradata <vmname> “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “0″

BTW - My general experience with all virtualization (not specifically any) is that Host/Guest time sync may be unreliable depending on how it’s implemented and what the Host and Guest OS are. Much more reliable is to just set every Guest for NTP so that every Guest sets its own time independently.

HTH,
TSU

4

Thanks for the replies and thanks, wolfi, for pointing out that the errors are from a VMware service not a VirtualBox one. I must admit I’d not noticed that - I guess I just wasn’t expecting it! (But see below.)

Unfortunately, this doesn’t quite address my concern, though. In fact it makes it worse. Why would openSUSE have configured itself to start a VMware service when it’s running in a VirtualBox VM? Doesn’t that seem a bit odd?

A possible explanation is that on the guest there is a process running called “vmware-vmblock-” that sometimes eats a whole load of CPU time. It doesn’t look like a rogue process; it looks like it’s doing something that’s needed. If I stop the vmtoolsd system service, that process goes away, but I then get I/O errors when I reference the /sys file system. So that suggests that the vmtoolsd (i.e. VMware) system service is started for a reason (even in a VirtualBox VM) and therefore that the error messages could be significant.

BTW, when I refer to “running commands on the guest from the host” I’m referring to using the VBoxManage guestcontrol interface (and, yes, I’m familiar with the time sync problems in VMs:(). This allows you to run images on the guest from a script running on the host and needs VBoxService to be running on the guest. This is basically what I need to get working, but I can’t decide whether it should be running by default and/or whether something has gone wrong starting it.

What I’m seeing could conceivably be normal behaviour, I guess. What would really help me decide is if someone with an openSUSE guest in VirtualBox could confirm what VBox* processes are running on the guest, whether the “vmtoolsd” service is running and whether it starts without errors.

With what I currently know, I think the errors could justify a bug report, but I’d really like to check that it’s not just my system that’s showing this behaviour.

5

Just noticed that wolfi confirms VBoxService doesn’t run by default - so that’s one point ticked off.

So I think I just need to know now whether the vmtoolsd service produces errors when it starts for anyone else but me. Any takers?

6

No.
The LiveCD has installed and enabled both VMware and VirtualBox guest tools on purpose, so that it works good inside both VMware and VirtualBox. (it is a LiveCD after all)

When you install from the LiveCD, just the complete content is copied to the hard disk, it is not really installed.

If you want to get rid of that VMware service, just uninstall the package “open-vm-tools”.

A possible explanation is that on the guest there is a process running called “vmware-vmblock-” that sometimes eats a whole load of CPU time. It doesn’t look like a rogue process; it looks like it’s doing something that’s needed. If I stop the vmtoolsd system service, that process goes away, but I then get I/O errors when I reference the /sys file system. So that suggests that the vmtoolsd (i.e. VMware) system service is started for a reason (even in a VirtualBox VM) and therefore that the error messages could be significant.

Hm, I have never seen something like that.
The vmtoolsd should just fail to start and not cause any problems. If it does, it would be a bug.

Anyway, you can just uninstall it, see above.
It should not be needed at all inside VirtualBox.

What I’m seeing could conceivably be normal behaviour, I guess. What would really help me decide is if someone with an openSUSE guest in VirtualBox could confirm what VBox* processes are running on the guest, whether the “vmtoolsd” service is running and whether it starts without errors.

Well, I checked a Factory installation (a standard installation, not from the LiveCD) inside VirtualBox before replying, and as I wrote, there is no VBoxService running there.
If you want it ro run, you have to start it manually, or set it up to be started on boot/login.
Again, if you think this should be done automatically, you should file a bug report.
I cannot really judge, but personally I never had the need for starting it yet.

As my VM was a standard installation, there’s also no open-vm-tools installed there. So I don’t know whether that would cause problems. As said, it should not. If it does this should be reported.
I might try to install them later and check whether I see unusual behavior.

7

OK, I’ve done a few more tests, so an update.

The issue of I/O errors if the vmtoolsd service is not running seems to be a red herring. I now get the errors whether it’s running or not (I think my “grep” test just wasn’t reaching /sys when I tried before). So there indeed seems to be no rationale for having it running.

However, the issue with the strange “vmware-vmblock-” process is confirmed. With the vmtoolsd service “running” (i.e. started with errors as happens with the default setup), I exercise the file system using “grep -r foobar /” as root. This makes the grep and vmware-vmblock- process consume about 60% CPU each (the VM has 2 cores).

With the vmtoolsd service stopped, the same test shows grep using about 3% CPU and no vmware-vmblock- process. It’s hard to know how much file caching affects these figures, but it looks to me like you could waste a lot of CPU if you have vmtoolsd running (BTW stopping the service doesn’t always seem to work, possibly because of the errors when starting it).

Another test I did was to disable vmtoolsd in yast service manager and then reboot the guest. The service disappeared completely from yast (which surprised me), there was no sign of any vmware-vmblock- process, and CPU use in the “grep” test was low. Restarting vmtoolsd by hand made it re-appear in yast and the process/CPU problems returned.

So I think I’ll just uninstall open-vm-tools as it looks like openSUSE isn’t handling it at all properly.

I’ll make a bug report if anyone else can confirm what I’m seeing.

8

Update your system!
The YaST Services Manager module had a bug in the version shipped with 13.1, in that it only showed legacy sysvinit services that are enabled.
This got fixed by an update.

Speaking of updates, there was an update to the VirtualBox guest tools as well that didn’t quite make it into the 13.1 release. This was an upstream bug in VirtualBox 4.2.18’s guest tools that caused hogging the CPU when shared folders were in use. So maybe the issue you’re seeing is actually this?
https://bugzilla.novell.com/show_bug.cgi?id=841673

So please install all updates before you file any bug report (always a good advise anyway :wink: ).

9

I did an update after installing from the CD. That was maybe a week ago, but to be thorough I’ve just done another followed by a reboot. There were 10 updated packages, including a new kernel and updates to the guest additions.

Unfortunately, none of this made any difference to any of what I’m seeing (even the disappearing service in yast still seems to be happening). I don’t have any shared folders mounted (or even attached) either.

10

PS: I did install open-vm-tools in my Factory VM now, but there I cannot reproduce what you described.
I do not get any vmware-block-* processes when I enable it or manually start it.

And “systemctl status vmtoolsd” tells me this:

vmtoolsd.service - service for virtual machines hosted on VMWare
   Loaded: loaded (/usr/lib/systemd/system/vmtoolsd.service; enabled)
   Active: inactive (dead)
           start condition failed at Fr 2014-06-27 17:32:29 CEST; 2min 15s ago
           ConditionVirtualization=vmware was not met
     Docs: http://open-vm-tools.sourceforge.net/about.php

So vmtoolsd has a native systemd unit now, which contains “ConditionVirtualization=vmware”. So it should not at all be started (not even tried to be started) any more outside of VMWare (this seems to be a new systemd feature).
Something like you describe shouldn’t therefore be possible at all in Factory/13.2.

I have yet to try an installation via the 13.1 LiveCD, this might take a while though…

11

Especially that YaST problem should really not happen.

Did you really install all updates? Try again please, either YaST->Online Updates or “zypper up”.

If there are updates to the software stack available, only those are installed and the rest is ignored.

Btw, that “ConditionVirtualization=” option is not new in Factory’s systemd. It is already available in 13.1.
From 13.1’s “man systemd.unit”:

           ConditionVirtualization= may be used to check whether the system is
           executed in a virtualized environment and optionally test whether
           it is a specific implementation. Takes either boolean value to
           check if being executed in any virtualized environment, or one of
           vm and container to test against a generic type of virtualization
           solution, or one of qemu, kvm, vmware, microsoft, oracle, xen,
           bochs, chroot, uml, openvz, lxc, lxc-libvirt, systemd-nspawn to
           test against a specific implementation. If multiple virtualization
           technologies are nested, only the innermost is considered. The test
           may be negated by prepending an exclamation mark.

This doesn’t apply to vmtoolsd on 13.1 though, as it still has a legacy sysvinit script there.
So in theory your problem can happen on 13.1 as vmware-vmblock-fuse is started unconditionally there by that init script (but I would call it a bug in open-vm-tools then).

Not sure whether that’s worth a bug report though, as it already is fixed in Factory, by having a native systemd unit with “ConditionVirtualization=vmware”. Even if there would be an update to 13.1, the LiveCD wouldn’t be re-released and would still contain the old version.

Anyway, I’m downloading the 13.1 KDE LiveCD now, I’ll see whether I can reproduce this.

12

Just a quick note while the 13.1 LiveCD is being installed in VirtualBox.

I can reproduce one thing on my “real” 13.1 system, where I installed “open-vm-tools” now.
When I start vmtoolsd.service, I have that vmware-vmblock-fuse process running as well.
But it uses zero CPU time, even if I run that “grep” command you mentioned.

And YaST Services Manager still shows the vmtoolsd service even after I stopped and disabled it again.

13

So I replied to soon.
15 minutes later, vmware-vmblock-fuse did suddenly use a lot of CPU time. (I had it running for about 15m already when I replied…)

But I can exactly tell you where: /run/vmblock-fuse/dev
This is of course created by vmware-vmblock-fuse, it’s used to communicate with it apparently.

When grep accesses this, it’s clear then that the process starts getting busy…
I suppose the same can happen with other system directories/files as well.
F.e. “grep foobar /dev/random” will never finish as long as your random number generator doesn’t run out of numbers. :wink:

I wouldn’t call this a bug though.

I’d suggest to just uninstall open-vm-tools and forget about it.
The only thing that you could regard as a bit fishy here is that maybe vmware-vmblock-fuse shouldn’t be left-over when vmtoolsd.service fails to start.
But that shouldn’t give problems under normal circumstances.
And as mentioned it should not happen at all in upcoming openSUSE versions, as it should not even be possible to start vmtoolsd.service there.

The errors about /sys are perfectly normal as well. There just is stuff in there that not even root can access or that just doesn’t make sense to be accessed by grep f.e. It’s a direct interface to the kernel.

14

Thanks for all your efforts in getting to the root of this. I’m going to do as you say and uninstall open-vm-tools, pretend it all worked fine and wait for the fix to work its way through in a later version of openSUSE (yes, I had assumed that the errors on /sys were just a case of inappropriate use of grep).

A couple of remaining issues, though:

  1. The vmtoolsd service is still disappearing from yast services manager when disabled. I’ve re-checked the system update and run “zypper up” until there’s nothing left to do. Then I’ve re-booted. I found that after the recent kernel update the guest system wouldn’t reliably reboot until I’d powered off the VM. But it seems to be back to normal now.

If it helps, I appear to have yast2-services-manager version 0.0.11-3.4.1 installed. Last change seems to have been on 4th Nov 2013 “list missing LSB services” #846422.

  1. I need to start VBoxService when the system boots. No problem, but maybe you could suggest the best way to do this in openSUSE?

Many thanks again.

15

Yes, this is the fixed one.
Hm, vmtoolsd.service didn’t disappear here.

But services that return an error (when “/etc/init.d/xxx status” is called) won’t get displayed. Maybe it does return an error inside VirtualBox, and therefore it disappeared? I only tried on my “real” system.

  1. I need to start VBoxService when the system boots. No problem, but maybe you could suggest the best way to do this in openSUSE?

It is to be started as root, right?
You could add it to one of the boot scripts.
/etc/init.d/after.local would be appropriate I think. To make this run at boot, “after-local.service” has to be enabled, but it should be by default.

16

That didn’t quite work. But that’s probably because there’s no link to /etc/init.d/after.local in any of the /etc/init.d/rc?.d directories (which I think means the service isn’t enabled?). I added a soft link in rc2.d alphabetically immediately after the link for vboxadd and now it seem to work.

No indication of whether the service is enabled in yast of course, as it doesn’t even appear :rolleyes: (but then I stopped using yast for service information years ago as I’ve never found it reliable).

17

You should not create symlinks in /etc/init.d/rcX.d/ manually. Better use “chkconfig” or “systemctl”.

But /etc/init.d/after.local is not supposed to be started in runlevel2 anyway.
It should get started by after-local.service, as I wrote.

If that is too late, you could also try /etc/init.d/boot.local, which is started by rc-local.service.

Both of those services get started on my 13.1 system during boot, without me having done anything manually to enable them:


2014-06-30T13:34:59.649064+02:00 amiga systemd[1]: Starting /etc/init.d/boot.local Compatibility...
2014-06-30T13:34:59.674583+02:00 amiga systemd[1]: Started OpenSSH Daemon.
2014-06-30T13:34:59.681236+02:00 amiga systemd[1]: Started /etc/init.d/boot.local Compatibility.
...
2014-06-30T13:35:25.719712+02:00 amiga systemd[1]: Starting /etc/init.d/after.local Compatibility...
2014-06-30T13:35:25.759917+02:00 amiga systemd[1]: Started /etc/init.d/after.local Compatibility.

No indication of whether the service is enabled in yast of course, as it doesn’t even appear :rolleyes: (but then I stopped using yast for service information years ago as I’ve never found it reliable).

You’re right, after-local.service is not shown in YaST. Probably because you are not supposed to enable/disable/start/stop it.

systemctl status after-local.serviceafter-local.service - /etc/init.d/after.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/after-local.service; static)
   Active: active (exited) since Mon 2014-06-30 13:35:25 CEST; 15min ago
  Process: 1184 ExecStart=/etc/init.d/after.local (code=exited, status=0/SUCCESS)
 Main PID: 1184 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/after-local.service

As you can see, it is a static service.

18

OK, static services are new to me, but I think I get the idea. Checking the system log, both after.local and boot.local do get started by default. If I put a /usr/bin/VBoxService command in them it seems to get executed and the daemon starts, but by the time I log in it has gone away. So I’m not sure what’s happening here, given that my kludge with the link in rc2.d seems to work fine.

However, after much googling, I came across this page which seems to do pretty much what I need: http://seife.kernalert.de/blog/2011/11/22/a-trivial-systemd-unitscript/

So now I have this in a file called /etc/systemd/system/vboxservice.service:

[Unit]
Description=VirtualBox VBoxService service (time sync, guest control, etc.)

[Service]
ExecStart=/usr/bin/VBoxService -f

[Install]
WantedBy=default.target

This seems to work OK and the service shows up properly in yast and can be enabled and disabled which is convenient. However, if I understand things correctly, it gets started at runlevel 5 which is probably a bit late.

There are a couple of issues here. One is that I want to use the VBoxService interface to configure the VM, which may involve going into (say) single user mode, so I don’t want this service to stop if I do that.

The other issue is that the time sync doesn’t work until VBoxService starts. Currently, the time stamps in the system log are way out (many hours in the future) until the service gets going. That seems bad, so getting vboxservice.service running ASAP seems to be a good idea.

So how can I change this file to start the service earlier?

19

There are no runlevels with systemd. (although it does provide some compatibility)

You can define the order in which services start by specifying After= or Before= statements.

If you want to have it run in single user mode as well, just add “WantedBy=rescue.target”, I’d say.
And maybe it’s better to use “WantedBy=multi-user.target” instead of default.target.

In your case, it should maybe be set to start “Before=syslog.service”?

But I thought VirtualBox would take the host system’s clock as reference on startup anyway. Why would the syslog timestamps be hours in the future? This sounds strange.
Using ntp might help as well though.

20

On 2014-06-30 18:46, wolfi323 wrote:

> In your case, it should maybe be set to start “Before=syslog.service”?

Probably.

> But I thought VirtualBox would take the host system’s clock as reference
> on startup anyway. Why would the syslog timestamps be hours in the
> future? This sounds strange.

The guest should get the time from the emulated bios clock during boot.
I would check the guest machine bios config (I suppose that virtualbox
emulates one, same as vmware does), and check the clock in there, the
“guest bios”.

If that is incorrect, then virtualbox has a problem. If it is correct,
the procedure is the same as in a normal openSUSE install to correct the
time, without guest tools running. Once they run, the point is moot.

> Using ntp might help as well though.

No, don’t. Never use ntp in a guest machine. It causes overhead, and you
can not discipline the guest CPU, anyway (it shares cycles with the
host)). Run ntp only on the host, and then tell the guest to pick the
time from there, typically using guest tools.

And least on vmware site there is a long article explaining why ntp
should not be used on guests.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)