Kernel updates in VM with Ubuntu 18.04 host (kernel 5.0.0.x) takes very very long time

[antarx882p]

I noticed that updating the kernel with the Software Updater takes very long time (in the guest system - not the host).
I am running three different VMs in VirtualBox: Ubuntu 16.04, Ubuntu Budgie 18.04 and Ubuntu 19.04.
The host machine has been running Ubuntu Budgie 18.04 with the original kernel 4.15 for more than a year without issues. I have been using VirtualBox 5.2 until recently.
I had to reinstall the host machine due to HW failure. I reinstalled using Ubuntu Budgie 18.04.3 and noticed that the kernel is now 5.0.0.x (with HWE).
Now it takes extremely amount of time to update the kernels in the guest VMs.
Obviously this has something to do with the host running 5.0.0.x but how can this be? How can it affect the time it takes to update the kernels in the Virtual machines?

The guest - Ubuntu Budgie 18.04 - updated from 5.0.0.27 to 5.0.0.29 in 2 minutes on a Windows 10 host.
On my Ubuntu Budgie 18.04 host (Intel i5-3570K) the same update took 32 minutes!
I have noticed the same problem with all VMs (guest systems Ubuntu 16.04, Ubuntu Budgie 18.04 and Ubuntu 19.04).
Ubuntu 16.04 is running kernel 4.15.
Would appreciate any suggestion how to solve this issue. If I can't solve it I have to use the Windows host for instead which I do not like .

VirtualBox version is 6.0.10.

[socratis]

The "takes very long time" can only mean one thing in my book; slow connection to the update servers. Did you happen to have System Monitor running during the updates? If not try it again.

Plus, this is something that's easily reproducible, unless you took a snapshot of your VMs just before upgrading, so that you could revert back. Did you?

[antarx882p]

No. It has nothing to do with the update servers I think as the updates have already been downloaded.
The problems seems to be related to unpackaging the software which takes very long time (> 30 minutes).
It is something related to the kernel in the host I think. Linux kernel 5.0.0.x has this problem - Linux kernel 4.15 does not have this problem.

[antarx882p]

I always use snapshots so I reverted back.
I have the problem since I installed the new system Ubuntu Budgie 18.04.3 on the host three weeks ago.
All three VMs (Ubuntu 16.04, Ubuntu Budgie 18.04 and Ubuntu Budgie 19.04) now takes very long time to update when a new kernel is released.
I have never had the problem before (earlier my host was running Ubuntu 18.04 kernel 4.15 without HWE). I think that HWE has something to do with the problem.
Bug #947664 on launchpad mentions something similar (comment #31 and #32 by S. Christian Collins).
Comment #32:
"Okay, so I have narrowed this down a bit. The issue is the kernel version on the HOST system, not the GUEST. I tested this by installing the package "linux-headers-5.0.0-23" on a Xubuntu 18.04 guest in VirtualBox using two different kernels on the host PC. I used the command "time sudo apt install linux-headers-5.0.0-23" to report the total time for the process to complete. Here is how long the package installation took when running on each host OS kernel, not counting package download time (it was already in the apt cache):

Kernel 4.17.19-generic (and earlier): 20 seconds

Kernel 4.18-rc1-generic (and later): 8 minutes, 43 seconds

Using kernel 4.18 or later is almost 23 times slower!"

[klanten]

I hope I'm not hijacking the thread, but I have the same problem with Debian 10 as host. No matter whether I update the kernel on any of my guests - which are Debian 8,9,10 and Ubuntu 19.04, the part of the install where it says 'Unpacking' of linux-image, linux-headers, and linux-headers-common always takes between two and four minutes per file or around ten minutes total. On a recent update of the kernel on my host, the unpacking took seconds.There are other slowdowns when install a new version of Libreoffice and other programs, but the kernel unpacking is the slowest.

I have 16GB memory on the machine with 4 GB per guest OS. Cpu is a I5-4570. This problem did not show up on Debian 9 as host. And a recent test of the HD with smartmontools didn't show anything alarming.

Oh, and any of the other guests including Fedora, Arch, OpenSuse, OpenIndiana and so on, do not show slowing.

Thank you.

[antarx882p]

No you did not "klanten" Swedish?
There is a possible solution to test as suggested by "S. Christian Collins" in this thread (refer to comment #34):
https://bugs.launchpad.net/dpkg/+bug/947664

The solution would be to turn "Use Host I/O Cache" on for the SATA controller.

I also found the following blog post on this subject why activating this option might be a good idea (and also why it is not by default):
https://www.electricmonk.nl/log/2016/03 ... erformance

I will try it on the next kernel update to see if it might solve this issue.

[klanten]

Beautiful, thank you so much. I tried the fix and it seems to work. I did read the bit about losing data, but I rather think I'll chance it. My apologies for not reading your post more carefully.

Jo, inte svensk men kan svenska.

[antarx882p]

Ok. Det låter bra
I haven't been able to test it yet. But it should make a difference.
On next kernel update I will test with an without this option enabled.

[klanten]

I updated my two Ubuntu guests yesterday (19.04 Gnome and 19.04 Mate), and they were done extremely quickly - in seconds. Don't know which cache is referred to in the fix, but my hard drive is a Seagate Enterprise with 128 MB cache. Would that affect anything?

But the results were astounding, particularly compared to the 8-10 minutes before. Oh, and a quick wipe went much faster.

Thanks for your research.

Much too fast to post, but the updates were to 5.0.0.31

[antarx882p]

I just updated my Ubuntu Budgie 18.04 VM from Linux kernel 5.0.0.29 to 5.0.0.31 and I also found the update to be much faster with the "Use Host I/O Cache" option turned on.
In my case the same update without this option enabled took 30+ minutes.
With the option enabled the update took between 1-2 minutes (with the Chromium Web Browser being updated at the same time).
So I think we can conclude that this option makes a big difference.
The question remains though why this a problem with newer Linux kernels and not in older kernels.

One question to the developers of VirtualBox.
The documentation states the following (chapter 5.7. Host Input/Output Caching):
"If you decide to disable host I/O caching for the above reasons, Oracle VM VirtualBox uses its own small cache to buffer writes, but no read caching since this is typically already performed by the guest OS."

Can the cache be increased?