@mlcrane You're welcome! If everything started correctly, you should see this in Xen Orchestra along with VM IP: [image: 1760383624584-9df72e83-29ba-4166-b4bd-50d75f90cc87-image.png] The previous error you had "Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider" didn't quite make sense to me since the driver package was signed by Microsoft, perhaps you were missing an important update at the time, or your VM clock was out of sync?

@bleader IIRC I just "tried again". It failed 2 times, then I looked up the logs from other console, removed the file (which shouldn't be of any importance for our instance) and retried without reboot. I copied the whole installer-log to the usb stick before finshing the install. (Could actually be a good hint or even a menu-option for those, where the install fails and won't leave it on the harddrive - e.g. evaluating hardware) [ 128.517356] ata1.00: exception Emask 0x0 SAct 0x800000 SErr 0x0 action 0x0 [ 128.517357] ata1.00: irq_stat 0x40000008 [ 128.517359] ata1.00: failed command: READ FPDMA QUEUED [ 128.517362] ata1.00: cmd 60/80:b8:10:6c:d4/00:00:02:00:00/40 tag 23 ncq dma 65536 in res 41/40:10:80:6c:d4/00:00:02:00:00/00 Emask 0x409 (media error) <F> [ 128.517363] ata1.00: status: { DRDY ERR } [ 128.517364] ata1.00: error: { UNC } [ 128.518008] ata1.00: configured for UDMA/133 [ 128.518018] sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 128.518020] sd 0:0:0:0: [sda] tag#23 Sense Key : Medium Error [current] [ 128.518021] sd 0:0:0:0: [sda] tag#23 Add. Sense: Unrecovered read error - auto reallocate failed [ 128.518024] sd 0:0:0:0: [sda] tag#23 CDB: Read(10) 28 00 02 d4 6c 10 00 00 80 00 [ 128.518025] print_req_error: I/O error, dev sda, sector 47475840 [ 128.518039] ata1: EH complete [ 128.581286] ata1.00: exception Emask 0x0 SAct 0x2000000 SErr 0x0 action 0x0 [ 128.581287] ata1.00: irq_stat 0x40000008 [ 128.581288] ata1.00: failed command: READ FPDMA QUEUED [ 128.581291] ata1.00: cmd 60/08:c8:80:6c:d4/00:00:02:00:00/40 tag 25 ncq dma 4096 in res 41/40:08:80:6c:d4/00:00:02:00:00/00 Emask 0x409 (media error) <F> [ 128.581292] ata1.00: status: { DRDY ERR } [ 128.581293] ata1.00: error: { UNC } [ 128.582111] ata1.00: configured for UDMA/133 [ 128.582117] sd 0:0:0:0: [sda] tag#25 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 128.582118] sd 0:0:0:0: [sda] tag#25 Sense Key : Medium Error [current] [ 128.582119] sd 0:0:0:0: [sda] tag#25 Add. Sense: Unrecovered read error - auto reallocate failed [ 128.582121] sd 0:0:0:0: [sda] tag#25 CDB: Read(10) 28 00 02 d4 6c 80 00 00 08 00 [ 128.582122] print_req_error: I/O error, dev sda, sector 47475840 [ 128.582133] ata1: EH complete [ 128.629307] ata1.00: exception Emask 0x0 SAct 0x200 SErr 0x0 action 0x0 [ 128.629309] ata1.00: irq_stat 0x40000008 [ 128.629310] ata1.00: failed command: READ FPDMA QUEUED [ 128.629313] ata1.00: cmd 60/08:48:80:6c:d4/00:00:02:00:00/40 tag 9 ncq dma 4096 in res 41/40:08:80:6c:d4/00:00:02:00:00/00 Emask 0x409 (media error) <F> [ 128.629314] ata1.00: status: { DRDY ERR } [ 128.629315] ata1.00: error: { UNC } [ 128.630068] ata1.00: configured for UDMA/133 [ 128.630074] sd 0:0:0:0: [sda] tag#9 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 128.630076] sd 0:0:0:0: [sda] tag#9 Sense Key : Medium Error [current] [ 128.630077] sd 0:0:0:0: [sda] tag#9 Add. Sense: Unrecovered read error - auto reallocate failed [ 128.630078] sd 0:0:0:0: [sda] tag#9 CDB: Read(10) 28 00 02 d4 6c 80 00 00 08 00 [ 128.630079] print_req_error: I/O error, dev sda, sector 47475840 [ 128.630092] ata1: EH complete Indeed it looks like the SSD should be replaced. 8.3 is running stable on this (and all other hosts, I upgraded) so far. It's a system at a UAS, running various student projects for several years now, coming from XenServer originally. I voluntarily maintain it. Thx for the hint!

@dinhngtu I can't say on XCP-ng side, but it's likely linked to: August patch (and following), as Microsoft changed something to the NVMe stack. e.g. https://learn.microsoft.com/en-us/answers/questions/5536733/potential-ssd-detection-bug-in-windows-11-24h2-fol Google gives a lot about it. It seems that it most likely doesn't kill NVMes but can cause trouble. We have a few PCs becoming more unstable (BSODs) or even very slow after that upgrae.

I often wondered what's the general purpose of that option. As I only have 1 - 2 socket servers, I always choose 1 socket with x cores (mostly 2 - 8, not exeeding 1 real CPU). Also for historic reasons: Sockets have been limited, but not cores. Does it generally make any difference on Xen side/backend? VM OS might handle it different due to NUMA optimizations.

@dfrizon said in How to protect a VM and Disks from accidental exclusion: @olivierlambert The idea is to block the VM and exclusion disks even by root itself, and make it possible only via command line in the console. That's why I started the post by mentioning the command... We dream of the day when MFA authentication will be required to delete a VM... How would you prevent the root account from taking action..... that is the absolute opposite permission set of root, as if there is an account with even more permissions than root. You can use permission sets and move your team who are deleting powered off VM's that are protected from accidental deletion into a group that doesn't have the permission to delete VMs, at the same time, remove their permissions from deleting items from your SR. I think that would solve your problem, and doesn't cause any logical permission issues like above.

@olivierlambert Ideally XCP-ng (xapi) could add this to a queue, and wait for some time before cancelling the task because it took too long. This also needs some kind of feedback that can be given to the user / client, which I think currently is quite undercooked (how to report is waiting on other migrations to the same host when a client asks?). For the time I think XO being aware that it can retry the operation would be simpler, especially because it already has code to do it for other operations

Maybe a bad command that overwrote the file, anyway glad you managed to make it work!

The unusual one happened to occur on a Master (though not all Masters have this reverse ordering).

Right now, it's XO -> Netbox only. As soon as you want something bidirectional, the complexity is exponential. I'm not closed to the idea, but we need to carefully think about the how and what's really expected functionally speaking from our users

It's not a trivial scenario indeed. Dom0 is a PV guest (in other words: a VM) on top of an hypervisor (Xen), on top of an hypervisor (HyperV). As you can see, more layers means more problems

Sorry, I'm asking if I should be good deleting the snapshots

@AtaxyaNetwork said in Unbootable VHD backups: @Schmidty86 Try to detach the disk and reattach, it should be xvda in order to be bootable That's what I was thinking as well, but obviously something is off with this VM. @Schmidty86 is the old host still online? If so you might be able to perform a Live Migration or a replication job to copy it from the old host to the new.

AlmaLinux 8.10

Hello, thank you for your reply @bogikornel @TrapoSAMA . Here are my processor specifications: Intel Xeon E5-1620 v2 (8) @ 3.691GHz. Unfortunately @Andrew , I have to use RHEL 10 on my server ^^ but thank you for providing the link. I will change my processor/server.

I worked with ChatGPT on this for a bit. We have narrowed it down to an issue with the NFS Storage that I ship the backups to. "When you recreated storage and moved data back, OMV is technically exporting a different underlying filesystem object than before. NFS clients that had an old handle cached (your XCP-ng host) try to access it and get ESTALE. That explains the initial backup errors and why deleting/re-adding the SR is failing now." I had to remove the NFS storage from XCP-ng, then delete the NFS share from OMV, then add the NFS share back to OMV, and then add it back to XCP-ng. I probably could have resolved this with a reboot, but I didn't wanna. This issue is resolved now.

As @Andrew said, your host itself is unhealthy, you might be able to disassemble the CPU and heatseat, clean it up and add some new paste to address the issue with the CPU overheating (if the paste is shot). As for the memory issue, run a memtest on the host and see what is reported.

@santos_luan Check if there is any firewall issue on the XO-ce side.

Just quickly chiming in to confirm what @bleader said. We'll be happy to assist you further, especially to put you in contact with our head of security at Vates to discuss our future certification plans (he's a former ANSSI employee BTW).

CPU speed is great to enhance all Xen operations (using grants for example). But tapdisk got a lot of room to be better outside that, thanks to multiqueue and so on. However, it's not clear if it's better to improve tapdisk or making something different. This is an active topic of reasearch.

@acebmxer said in Windows Server not listening to radius port after vmware migration: After migrating our windows server that host our Duo Proxy manager having an issue. [info] Testing section 'radius_client' with configuration: [info] {'host': '192.168.20.16', 'pass_through_all': 'true', 'secret': '*****'} [error] Host 192.168.20.16 is not listening for RADIUS traffic on port 1812 [debug] Exception: [WinError 10054] An existing connection was forcibly closed by the remote host After the migration I did have to reset the IP address and I did install the Xen tools via windows update. Any suggestions? I am thinking I may have the same issue if i spin up the old vm as the vmware tools were removed which i think effected that nic as well.... On your VM that runs the Duo Auth Proxy service, check if the service is actually listening on the external IP or if its just listening on 127.0.0.1 If its just listening on 127.0.0.1 you can try to repair the Duo Auth Proxy service, take a snapshot before doing so. Also, if you're using encrypted passwords in your Duo Auth Proxy configuration you probably need to re-encrypt them, just a heads up, since I just had to do so after migrating one of ours. Edit: Do you have the "interface" option specified in your Duo Auth Proxy configuration?