@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

@JB @gregbinsd The fix has not been merged with the master branch yet, so you won't have the fix yet. Follow this pull request https://github.com/vatesfr/xen-orchestra/pull/10282 When you see an entry at the end of the activity log which says something like ' merged commit [commit ID] into master' then you'll know the fix has been added to the master branch. It's important to know that they could close this pull request without committing it to the master branch if they want to approach the resolution in a different way (this has already happened once with this issue).

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.

@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 Something called "Elpha Secure" ...none of our other antivirus shows it being bad but I wanted to ask around before I unflagged it.

I've finished work on the RBD SR driver. Packaged as an RPM which makes sure the other kernel module drivers are required (otherwise the newer RBD features aren't available) and it doesn't require any rbd tooling on the dom0. https://imirc.nl/xcpng/sm-additional-rbd-2.0-1.xcpng8.3.noarch.rpm This needs a cephx key to have dom0 access the rbd images and a ceph mgr user/pw to manage the SR. The driver creates a rbd namespace with the sr-uuid as it's name and the images are the vdi-uuid. so multiple sr's on the same ceph rbd pool are supported. If leverages the xen-blkback dom0 to expose the vdi to the guest. No tapdisk, qcow2 or vhd involved. Uses native RBD snapshots, leveraging the new vdi_revert and uses GC to flatten and clean snapshots and images when required. I'll be setting up a git repo with my sources for the kernel modules and sr driver for anyone to dive into the sources and perhaps help testing and improving this, The next thing I'm diving into is SXM and SMAPIv3 version as I guess those are the missing parts to make this future proof.

@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.