Discuss the 6.0.14 release

[arudnev]

Discuss the 6.0.14 release here.
You can download the release here.
VirtualBox 6.0.14 is a new maintenance release.

Known new issues/regressions
These are new and confirmed tickets about issues with 6.0.14:

• None so far.

See also:

• "Known Issues" with 6.0.0
• "Known Issues" with 6.0.2
• "Known Issues" with 6.0.4
• "Known Issues" with 6.0.6
• "Known Issues" with 6.0.8
• "Known Issues" with 6.0.10
• "Known Issues" with 6.0.12

[IanL22]

Hey,

I'm running a CentOS 8 VM, and the guest additions are being recompiled every single boot adding ~20 seconds to the boot time. I also see it on a Ubuntu 18.04 VM.

Please fix.

[socratis]

I'm running a CentOS 8 VM, and the guest additions are being recompiled every single boot

I also see it on a Ubuntu 18.04 VM.

You're doing something wrong! Are you sure you actually installed CentOS8 and Ubuntu18.04? And not running from a LiveDVD?

[IanL22]

This is what I see every boot:

Nov 10 18:26:11 localhost.localdomain systemd[1]: Starting vboxadd.service...
Nov 10 18:26:12 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions: Starting.
Nov 10 18:26:13 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel
Nov 10 18:26:13 localhost.localdomain vboxadd[975]: modules.  This may take a while.
Nov 10 18:26:13 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions: To build modules for other installed kernels, run
Nov 10 18:26:13 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
Nov 10 18:26:13 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions: or
Nov 10 18:26:13 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
Nov 10 18:26:25 localhost.localdomain vboxadd[975]: ValueError: File context for /opt/VBoxGuestAdditions-6.0.14/other/mount.vboxsf already defined
Nov 10 18:26:25 localhost.localdomain vboxadd[975]: VirtualBox Guest Additions: Running kernel modules will not be replaced until
Nov 10 18:26:25 localhost.localdomain vboxadd[975]: the system is restarted

The vboxadd systemd service actually unconditionally calls setup,

Code: Select all   Expand viewCollapse view

start()
{
    begin "Starting."
    if test -z "${INSTALL_NO_MODULE_BUILDS}"; then
        # We want to build modules for newly installed kernels on shutdown, so
        # mark the ones already present.  These will be ignored on shutdown.
        rm -f "$SKIPFILE_BASE"-*
        for setupi in /lib/modules/*; do
            KERN_VER="${setupi##*/}"
            # For a full setup, mark kernels we do not want to build.
            touch "$SKIPFILE_BASE"-"$KERN_VER"
        done
    fi
    setup
    .
    .
    .


[socratis]

'IanL22', is this something that you only see with 6.0.14? Is this a regression?

We need to see a complete VBox.log, from a complete VM run, where the problem occurs:

• Start the VM from cold-boot (not from a paused or saved state) / Observe or recreate the problem / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

[IanL22]

I don't believe it is something that happened before. I only noticed because my boot was taking AGES on vboxadd.service systemd unit.

graphical.target @28.683s
└─multi-user.target @28.683s
  └─vboxadd-service.service @19.868s +45ms
    └─vboxadd.service @2.470s +17.393s
      └─basic.target @2.463s
        └─sockets.target @2.463s
          └─spice-vdagentd.socket @2.463s
            └─sysinit.target @2.452s
              └─systemd-update-utmp.service @2.434s +17ms
                └─auditd.service @2.347s +84ms
                  └─systemd-tmpfiles-setup.service @2.271s +74ms
                    └─import-state.service @2.220s +49ms
                      └─local-fs.target @2.217s
                        └─run-user-42.mount @23.348s
                          └─local-fs-pre.target @2.076s
                            └─lvm2-monitor.service @997ms +816ms
                              └─dm-event.socket @993ms
                                └─-.mount
                                  └─system.slice
                                    └─-.slice

This guy seems to be complaining about the same thing in 6.0.2 ( viewtopic.php?f=1&t=91289#p438758 )

I've attached the log!

[socratis]

This guy seems to be complaining about the same thing in 6.0.2 (viewtopic.php?f=1&t=91289#p438758)

And there was a followup by michael (developer) that this wasn't reproducible. There was no followup by the OP, 'hotjava1231'...

00:00:00.524065 File system of '/home/ian/Downloads/VBoxGuestAdditions_6.0.14.iso' (DVD) is ext4

Do not download the Guest Additions (GAs) ISO separately, it's a recipe for a disaster. Always use the GAs that come already bundled with your VirtualBox installation. See ch. 4.1. Introduction to Guest Additions.

00:00:00.548113 NumCPUs <integer> = 0x0000000000000004 (4)
00:00:00.703132 CPUM: Physical host cores: 4
00:00:00.703490 Full Name: "Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz"

You have assigned all your CPUs to the VM. The host is going to run low on resources, since VirtualBox cares about physical processors (cores), not logical ones (threads). Just check the link for your CPU above, and make sure you read the text in the "?" next to the "# of Cores" and "# of Threads" in that Intel page...

Other than that, your VBox.log looks fine. I don't see any evidence that you're booting from a LiveDVD. You are booting from the "hard disk", so I can't explain the need to recompile the GAs on each and every boot, unless there's something going on inside your guest(s).

I have both a CentOS8 and an Ubuntu18.04 VMs somewhere around here, I'll definitely take a closer look and let you know...

BTW, that's an interesting timing output you posted, what command did you use to get it?

[arQon]

It's just "systemd-analyze critical-chain". It's about as trustworthy as the rest of systemd's reports, i.e. not very, but it certainly CAN be useful at times.

I've seen IanL22's problem recently myself it's because the build fails. So the "Please fix" he's asking for is something he needs to be applying to his setup, not VBox itself or the devs. (Unless he's trying to use an edger kernel that's changed some signatures).

@Ian - try to compile them yourself, in a terminal, and look at the output. That'll tell you what you're missing, which will probably be (compatible) kernel headers, or DKMS, or etc. Once you build the modules correctly the problem will go away and your boot times will be restored.

--

(Comments from a different forum from when I ran into this with the Ubuntu 19.10 Beta)

The other big offender turned out to be the VirtualBox guest modules, which were repeatedly being rebuilt at boot because the build was failing.
[snip]
See /usr/share/doc/virtualbox-guest-source/README.Debian on how to do that by hand.

[socratis]

It's just "systemd-analyze critical-chain".

Thanks for that! I'll check it out...

or DKMS

DKMS hasn't been used by VirtualBox since 5.0.0 was introduced. Only the forks required it...

[IanL22]

Hey,

1st, I was testing the Virtualbox Guest Additions from the site to ensure that the ubuntu binary repo wasn't in some way faulty. (I use the oracle repo)

2nd, An i7-2700k has hyperthreading, so I actually only gave the VM half my available logical cores, and I haven't had any performance issues.

3rd, I no longer think its rebuilding the entire thing, but it just so happens to be doing something slow on CentOS 8 (vboxadd is probably _not_ part of the critical chain on Ubuntu 1804)

I commented out these two lines in vboxadd-x11, which don't seem to do anything. (The context on the VBoxClient binary doesn't change, and the guest additions still appear to work)

Code: Select all   Expand viewCollapse view

chcon -t unconfined_execmem_exec_t '/usr/bin/VBoxClient' > /dev/null 2>&1
semanage fcontext -a -t unconfined_execmem_exec_t '/usr/bin/VBoxClient' > /dev/null 2>&1


And this removes vboxadd from the critical chain.

[socratis]

1. Good. Just wanted to raise the flag. This is a standard copy/paste reply whenever I see the GAs ISO used outside the main program, no harm done...
   
   
2. Logical cores don't matter to VirtualBox. The host is going to run low on resources, since VirtualBox cares about physical processors (cores), not logical ones (threads). See "CPU Cores versus threads" and "Why is it a bad idea to allocate as many VCPUs as there are physical CPUs?".
   
   I would strike a balance of 2 cores for the Guest and 2 cores for the Host.
   
   
3. It seems I got to do some reading on that "critical chain" thing, I got to understand a little better what's going on there.

[IanL22]

I don't know much about how virtualbox is implemented, but that doesn't grok.

I do know that the VT-x instructions that change from root to non-root mode are specific to the instruction stream (read hyper-thread), so it was no surprise to me that when I tried the experiment in the link, I saw exactly 2 cores in the host under load.

https://imgur.com/a/BglRb1f

[arQon]

> I don't know much about how virtualbox is implemented, but that doesn't grok.

Yeah, it doesn't - but that doesn't mean it's untrue.

The "standard forum advice" of "not more than half your core count" - and I really want to emphasise that it is *forum advice*, meaning it's based almost entirely on experience rather than strong technical knowledge - is both correct and incorrect, depending entirely on your use case.

There are genuine scenarios where e.g. assigning 4 VCPUs to a VM on a 4C/8T system *will* destroy the performance of *some* operations (say, networking, for example), regardless of the fact that the host remains 50% idle.
However, there are also scenarios where assigning 6+ VCPUs to a VM on the same system will produce hugely more performant results within that VM, with absolutely no measurable downside to any aspect of the entire system, including the host.
The "forum advice" IS fundamentally good advice, as it prevents users from running into unexpected issues. That doesn't mean it applies in all situations though, nor does it mean that you cannot choose to ignore that advice and be correct to do so IF your situation is one of those. But since the other forum members can't know what your scenario is, suggesting the "safe" path is the right thing for them to do, as it minimises the number of problems that other users could potentially end up asking for help with here.

If you have the appropriate technical background, an analogy may help you understand why:
Once upon a time, when hyperthreading was new, a lot of CPU cores had two INT pipelines but only one FMA per core. So on a 4C/8T CPU of that era, you WOULD get "full" 8-core performance for integer workloads, but you'd still only get 4-core performance for floating-point ops. Think of VCPUs that way, where the *core itself* is either in Host mode or Guest mode, but cannot be in both at the same time. If all 4 of your cores are in Guest mode, it *doesn't matter* that you still have 4 half-cores "free": all of your *FLOP* resources are in use, so those "free" cores are still execution-blocked behind the Guest workloads, and can't actually do anything until that stall is cleared.

(socratis, feel free to split these last few posts out of the 6.0.14 thread please, as they're not release-specific).

[Christian T. Tennyson]

Could you please guide us about the Virtual box and how can we use it?

[multiOS]

Could you please guide us about the Virtual box and how can we use it?

Try the User Manual. It's online: https://www.virtualbox.org/manual/UserManual.html or you can download a PDF version. The first few sections should get you started.