Comment by mey
7 years ago
I still scracth my head as to why doing a kernel update of Ubuntu running under Hyper-V on a spinning disk is so horrifically slow. If I migrate the VM while it's running to SSD, let it finish, then migrate it back to spinning, it's faster then just letting it update in place. This is my device desktop, otherwise I would put in on SSD full time.
The above comments make me think something like the stat calls may be the issue and moving the running vm to SSD hides the problem. It obviously isn't raw disk rate at the point.
Is the Ubuntu VM's / on a fixed or dynamic VHD? The former provides (modulo filesystem fragmentation) linear addressing of virtual LBAs to physical LBAs, and the latter can be heavily fragmented and result in sequential read/write operations becoming random access, which on a HDD kills performance.
My advice for anyone running VMs is if they're on HDDs or they're highly tuned for disk usage (databases for example), use fixed VHDs, otherwise use dynamic.
Thanks for the suggestion. The disk is a dynamic VHDX, migrated it to fixed vhdx and will experiment.
I still scracth my head as to why doing a kernel update of Ubuntu running under Hyper-V on a spinning disk is so horrifically slow.
Define slow please.
For a laugh I picked a random VM (VMWare) at work and ran (I did apt update first):
The updates included two client server DB engines (Clickhouse and Postgresql) the fileserving thingie (Samba) and a few other bits. The reboot takes about 90 seconds before the webby interface appears for rspamd.
Specifics,Host OS is Windows 10 Pro,virtual machine is Hyper-V, Guest OS is Ubuntu, Dynamic VHXD, Storage Space Pool with 4 HDD and 1 SSD, Windows Filesystem ReFS.
Only observe this specifically with kernel updates. Everything updates as I would expect on a HDD.
Slow is ~10-20 minutes. Which is why it is faster to migrate the running VM from the Storage pool, onto a single SSD, complete the ubuntu kernel update and migrate back.
Have you cleaned away the old kernel packages? Kernel package operations on Debian and Ubuntu are accidentally quadratic with a high time constant (there is a package script for each kernel that iterates over all installed kernels) so you want to make sure not to let them accumulate.
Has to be some kind of caching issue ...