Hi,

Following up on my own post.

Olaf Meeuwissen writes:

> Hi,
>
> Gregory Nowak writes:
>
>> On Mon, Nov 06, 2017 at 05:44:17PM -0500, zap wrote:
>
> # Actually, none of the quoted stuff was written by zap ;-)
>
>>> > I do have one question though, what ascii/stretch package name(s) should
>>> > I pass to `apt-get install`? Here's what I get for APT sources that
>>> > only reference `ascii{,-security,-updates,-backports}`.
>>> >
>>> > $ apt-cache search virtualbox-guest
>>> > virtualbox-guest-dkms - x86 virtualization solution - guest addition module source for dkms
>>> > virtualbox-guest-source - x86 virtualization solution - guest addition module source
>>> > virtualbox-guest-utils - x86 virtualization solution - non-X11 guest utilities
>>> > virtualbox-guest-x11 - x86 virtualization solution - X11 guest utilities
>>
>> At the very least, you want virtualbox-guest-dkms, and
>> virtualbox-guest-utils.
>
> And linux-headers-amd64 if you use APT::Install-Recommends=false ;-)
>
>> If your guest has x installed, then you'll want virtualbox-guest-x11
>> as well.
>
> It's a headless server, no X.
>
>>> > # There is no virtualbox-guest-additions-iso for ascii/stretch, only for
>>> > # jessie, buster and sid. The virtualbox-guest-additions package for
>>> > # wheezy just transitions to virtualbox-guest-additions-iso.
>>
>> They way I see it, one advantage of not using the iso is that the
>> packages will automatically be pulled in when upgraded versions are
>> available. So no need to mount a new iso, and upgrade by hand.
>
> Not so sure after my experience today because vagrant was complaining
> about a version mismatch for the guest additions (4 point something in
> the VM) and the Virtualbox version on the host OS (5.1.something). I'm
> not sure this matters (the vagrant message claims that "usually" things
> are okay) but it *is* a major version mismatch.

I nuked the VM, reprovisioned it and manually installed a matching
version of the guest additions. Vagrant no longer complained on start
up but the clock issue did not go away.

I did notice, though, that checking the VM after it had been running for
a couple of hours (> 5), there was only an approximate two minute clock
skew. Somewhat later it had increased to about six minutes. That does
not jive with my earlier statements of loosing 20 seconds to the minute.

I'm not sure if this has anything to do with the version of the guest
additions (I doubt it) or whether it is just that I never noticed that
the same thing was happening before.

>>> > From what I read in the package descriptions, virtualbox-guest-utils and
>>> > virtualbox-guest-x11 provide "stuff" to install in the guest. How does
>>> > that jive with installing these on the host? Or should I install these
>>> > on the guest? Does that mean the guest also needs virtualbox-guest-dkms
>>> > (and the toolchain required to build)? That would suck pretty badly,
>>> > IMO.
>>
>> All of these are installed in the guest, not in the host. Yes, the
>> virtualbox-guest-dkms is the source part of the kernel modules that
>> would be built by using dkms. The toolchain parts aren't that big.
>
> The VM is a fairly minimized server (stripped of anything that is not
> explicitly depended on). The toolchain etc added about 20%, IIRC.

It went from 826MB to 985MB, after cleaning out /var/{cache,lib}/apt/.
BTW, it meant to be used as a Jenkins slave for builds from git. Hence
the "bloat".

>> If you have another system with a toolchain and an identical running
>> kernel, you should be able to install virtualbox-guest-dkms there,
>> build the modules, and copy them over into your guest's
>> lib/modules. The system the modules would be built on doesn't need to
>> be a virtualbox guest as far as I know.
>
> That'd be an option but only if really necessary. It'd become a bit
> cumbersome if you use guests with lots of different kernels.
>
> Now back to me trying to get the host and guest to agree (and keep
> agreeing) on what time it is, I tried installed the guest additions (in
> the guest as well as the host), restarted and reprovisioned the image
> but to no avail. I keep losing 20 seconds per minute on the guest.
>
> I'll have another look again tomorrow and will try a matching version of
> the additions (if available). Failing that, I guess I'll have to take a
> look at the various virtualbox settings and command-line options.

See above.

> I did see something mentioning power management interfering and causing
> erratic behaviour. This may be a factor because the battery of the
> laptop that I'm testing on is close to dying (but I test when on AC
> power). Given that, I guess I could give Virtualbox a go on the target
> system(s) and see what happens.
>
> Anyway, the purpose is to keep my VMs on time, one way or another. It
> is just that a lot of the virtualization/containerization software out
> there comes with, and often defaults to using, Virtualbox support. If
> you want to use libvirt/KVM/QEMU, then the support becomes more of an
> "exercise left to the user" :-|

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join