🛰️ XO 6: dedicated thread for all your feedback!

[jr-m4]

Sometimes "# Disk Space" for VMs reports 0 in the central pane. But the assigned space is shown in the details (right) pane.

This is the same under Pool and Host-level. Sometimes it is shown, but after a reload of the page, it resets back to 0.

Marked the examples in red.

[ph7]

I removed 1 host from the pool and the local storage from that host didn't get purged

[ph7]

just found out that it's the same on XO5

[escape222]

Slow booting on Debian 13 VM created from a template

I recently tried cloning a VM from a template (created from a full install of Debian 13). What was noticed was that the system takes forever to boot when the VM is created from XO-6. The issue does not happen in XO-5. The VM seems to hang at the TianoCore boot screen .

What I noticed is that when the VM is cloned with XO-6 the boot order somehow changes to Network boot as the first option

This does not happen (change of boot order) if the VM is cloned from XO-5 and there is no boot delay. The boot process seems to wait for more than 2 minutes before it fails network boot and then proceeds normally to boot from the Hard drive

Thanks

[olivierlambert]

Thank you for the great feedback @escape222

Likely a bug indeed

[Greg_E]

@escape222

I assume you made it UEFI? I had the same problem with XO-lite about a year ago. If I created it as bios boot it worked as expected.

[escape222]

@Greg_E Yes it is UEFI

[Greg_E]

@escape222

Maybe try again as a BIOS boot VM, but the times for BIOS boot are nearing an end, so many things have climbed on UEFI only these days that a problem like this is going to be hard to ignore.

[MajorP93]

I noticed the same: for VMs that use UEFI the boot time is greatly increased compared to BIOS mode.

I noticed that VMs that have UEFI enabled show some "installing xen timer" and "spinlock" events in kernel log:

Apr 27 11:35:06 xo01 kernel: Xen: using vcpuop timer interface
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 0
Apr 27 11:35:06 xo01 kernel: smpboot: CPU0: AMD EPYC 7702P 64-Core Processor (family: 0x17, model: 0x31, stepping: 0x0)
Apr 27 11:35:06 xo01 kernel: cpu 0 spinlock event irq 52
Apr 27 11:35:06 xo01 kernel: Performance Events: PMU not available due to virtualization, using software events only.
Apr 27 11:35:06 xo01 kernel: signal: max sigframe size: 1776
Apr 27 11:35:06 xo01 kernel: rcu: Hierarchical SRCU implementation.
Apr 27 11:35:06 xo01 kernel: rcu:         Max phase no-delay instances is 1000.
Apr 27 11:35:06 xo01 kernel: Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
Apr 27 11:35:06 xo01 kernel: NMI watchdog: Perf NMI watchdog permanently disabled
Apr 27 11:35:06 xo01 kernel: smp: Bringing up secondary CPUs ...
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 1
Apr 27 11:35:06 xo01 kernel: smpboot: x86: Booting SMP configuration:
Apr 27 11:35:06 xo01 kernel: .... node  #0, CPUs:      #1
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 2
Apr 27 11:35:06 xo01 kernel:  #2
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 3
Apr 27 11:35:06 xo01 kernel:  #3
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 4
Apr 27 11:35:06 xo01 kernel:  #4
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 5
Apr 27 11:35:06 xo01 kernel:  #5
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 6
Apr 27 11:35:06 xo01 kernel:  #6
Apr 27 11:35:06 xo01 kernel: installing Xen timer for CPU 7
Apr 27 11:35:06 xo01 kernel:  #7
Apr 27 11:35:06 xo01 kernel: cpu 1 spinlock event irq 81
Apr 27 11:35:06 xo01 kernel: cpu 2 spinlock event irq 82
Apr 27 11:35:06 xo01 kernel: cpu 3 spinlock event irq 83
Apr 27 11:35:06 xo01 kernel: cpu 4 spinlock event irq 84
Apr 27 11:35:06 xo01 kernel: cpu 5 spinlock event irq 85
Apr 27 11:35:06 xo01 kernel: cpu 6 spinlock event irq 86
Apr 27 11:35:06 xo01 kernel: cpu 7 spinlock event irq 87

Those events seem to be what is slowing down boot.
Ever since I started using XCP-ng I was able to observe this behavior.
Once the VM is fully booted performance seems to be normal.
Maybe worth investigating at some point.

Best regards

[Greg_E]

@MajorP93

Before the LTS release UEFI worked extremely well, something kind of went sideways when it hit release. I only have a single UEFI VM, it was created under version 8.2 and does not give me trouble.

I guess I need to get my lab back up, had a UPS fail and shut everything off a few days ago. Then I need to test UEFI VMs and see what I can see. But back when it went LTS I reinstalled from scratch and tried to do everything through XO-lite to get the first VM running and found that Debian 13 or Windows Server 2022 would not boot if I created them with UEFI. Since then I haven't tested this again.

I'm also tempted to just move my whole lab to version 9, waiting for the next ISO to land and I may do this. I can run real testing workloads on Harvester for the time being and maybe play around migrating back and forth between both systems.