@poddingue said: I haven't used that tab myself, and since it's built around VMs that do have backups, I don't know if it gives you the negative view you want. If it doesn't, https://feedback.vates.tech is where that gets counted. Maybe you can build some sort of filter but I don't think so. I'll use https://feedback.vates.tech for future suggestions. Tks

@dicode-nl hello, very nice, I will definitely check it out!

It was too tempting not to test, so I went and tested the other half. On an 8.3 host I set the preferred resolution to 800x600 in the OVMF menu on a UEFI Debian VM, turned that VM into a template, and cloned it. The clone came up at 800x600. A control clone of the same original, with nothing set, came up at 1024x768. So your workaround holds, the resolution really does ride along into VMs built from the template. For anyone who wants to poke at it, the setting is a UEFI variable called PlatformConfig under GUID 7235c51c-0c80-4cab-87ac-3b084a6304b1. It only appears in NVRAM once you commit it in the menu, and it stores width and height as plain little-endian integers, which is why it travels with the VM record. One thing I didn't expect: the OVMF help text says the mode list is filtered against video RAM size, but the VM I used had the default 4 MB and still offered everything up to 1280x1024. So you may not need to raise videoram for the common ones. Fair warning though, I measured the console at the firmware stage rather than after the distro's own driver takes over, so a guest that sets its own mode later could still override it. At least, that's my understanding.

Thanks for chasing this with them, and for offering to post back after the call. Your Alma 10 read looks right (the 9.0 demonstrator is Xen 4.19 with a dom0 loosely based on AlmaLinux 10 and a 6.12 kernel), but @yann said in July they're out of prototyping and rebuilding the foundations component by component, so I wouldn't treat that kernel as the one their driver ends up targeting. On the packaging side, the kernel module policy page is the nearest thing I've found to an answer for what you'd need to pull together: https://docs.xcp-ng.org/project/development-process/kernel-module-policy For VROC, my understanding is that it sits on VMD, though I could have that backwards. VMD stalled boot on the demonstrator kernel back in January until yann said he'd include a patch for it, so that stretch of the thread is worth a read before your call: https://xcp-ng.org/forum/topic/11698 I don't know enough about driver packaging to say what Vates would actually need from GRAID, so it might be worth pulling in @Team-Hypervisor-Kernel, since drivers are their scope. If the call gives you a list of what they need from our side, that's probably the most useful thing to bring back here.

@christopher-petzel Ok! Thanks!

@mike.potapov Can you upgrade to the latest blktap-3.55.5-9.3.xcpng8.3 to check is the issue is still there?

@dinhngtu Hello. I've updated to the latest commit. There is no need to give me credit. I just want to help so others and myself included can benefit from this. Anyway thank you for your work.