@florent said: where does this disk comes from From my Redhat 10 @florent said: if you have access to your SR from the outside, you can also put the qcow2 file directly I create a VM to be a NFS to access the 3 HDs, the qcow disks are on the Redhat 10 that I was trying to import from. Do you mean I put the qcow disks on one of the HDs and access them when I create a VM?

@limezest You're right, we'll fix this. With this typo, the elif branch will always be false and not executed, it's dead code. As it is a less common issue than the first branch of the if, the script will left behind this particular case but will still fix the majority of snapshot_of problems. The script can still be used safely.

@dthenot said: you will also likely need to give the host-uuid of the host the disk is on Thanks, and I'm assuming this UUID or Machine ID from: [14:45 xcp-kbbn NAS]# dmidecode --type SYSTEM # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. # SMBIOS implementations newer than version 3.0 are not # fully supported by this version of dmidecode. Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ASUS Product Name: System Product Name Version: System Version Serial Number: System Serial Number UUID: E7AE9723-CB08-A278-5C45-7C10C9473BD0 Wake-up Type: Power Switch SKU Number: SKU Family: To be filled by O.E.M. OR [12:46 xcp-kbbn NAS]# hostnamectl Static hostname: xcp-kbbn Icon name: computer-desktop Chassis: desktop Machine ID: c668f529e66c42b9815fe12f3401df82 Boot ID: dd70b200b25341c688aee9fbc58d20a2 Virtualization: xen Operating System: XCP-ng 8.3 Kernel: Linux 4.19.0+1 Architecture: x86-64 the command would look like this correct: xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=E7AE9723-CB08-A278-5C45-7C10C9473BD0 or c668f529e66c42b9815fe12f3401df82 UPDATE: I tried the new command but I got these error messages: [14:45 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=E7AE9723-CB08-A278-5C45-7C10C9473BD0 The uuid you supplied was invalid. type: host uuid: E7AE9723-CB08-A278-5C45-7C10C9473BD0 [15:14 xcp-kbbn NAS]# ls [15:19 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=c668f529e66c42b9815fe12f3401df82 The uuid you supplied was invalid. type: host uuid: c668f529e66c42b9815fe12f3401df82 then I was successful (I believe with you confirmation) when I left our the host-uuid param: [15:19 xcp-kbbn NAS]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" b802722e-67ac-5aba-8d6c-e565d2d7fa0d and then it was listed as a SR: [image: 1779139583485-screenshot-from-2026-05-18-15-24-03.png] now to the next task command: xe sr-scan uuid=b802722e-67ac-5aba-8d6c-e565d2d7fa0d was successful, but I have another Question, the size of the device is not showing, is this normal being that it was done this way? UPDATE 2.0: I just discovered the xe command: [15:27 xcp-kbbn NAS]# xe host-list uuid ( RO) : 9a5e5bb3-bdb9-41ea-9505-6f6fe630f369 name-label ( RW): xcp-kbbn the uuid does not match the ones provided above, do I need to remove the SR and do it over again using this uuid? I will give it a try using another folder.... UPDATE 2.1: I executed the command using the above uuid: [15:35 xcp-kbbn srv]# xe sr-create type=udev device-config:location=/srv/NAS name-label="NAS Disks" host-uuid=9a5e5bb3-bdb9-41ea-9505-6f6fe630f369 6fc531a0-19a0-b9c1-c78e-c687fce5ff84 and was successful, but now my question for the device size, is it normal or not due to creating it this way? UPDATE 2.2: I forgot to do: ln -s /dev/sda /srv/NAS/sda #although it might be better to use a stable identifier if you have multiple disks xe sr-scan uuid=<UUID of the udev SR> be right back..... UPDATE 3.0: Success, I have all HDs attached to my VM, access all files and the sizes are reported! : [image: 1779147782991-screenshot-from-2026-05-18-17-25-38.png] List of attached disks: [image: 1779147797114-screenshot-from-2026-05-18-17-18-07.png] The VM: [image: 1779148373193-screenshot-from-2026-05-18-17-51-19.png] Thanks for your help!...

@johnnezero The full HTML versions will render much better. The PDF conversion is less than perfect. iIll try to get those uploaded, as well.

Hi! I think what you're seeing may be stale entries in the XAPI database, ghost records that can survive upgrades or host reconfigurations. From what I've read, xe vm-destroy uuid=<vm-uuid> removes the record without touching any storage, which seems like what you need here; the xe CLI reference confirms storage is left intact. I think you can get the UUID first with xe vm-list name-label="Before Ubuntu Update" (replacing the name with whichever one you're after). I'm not entirely sure why xsconsole would show them but XO wouldn't, so if the VMs don't turn up in xe vm-list, it might be worth a mention to Team-XAPI-Network, they'll know the right way to dig into XAPI state.

@poddingue there is a notion of appliance too (group of VMs) https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands where you can start/stop a group of VMs, never tried it, doesn't seem to have a boot order in the vAPP neither

@bvivi57 xo do check license if you have xostor installed, since it need some magic to work at a lot of steps ( like the rolling pool updates) this is the expected behavior with a manually installed xostor ( cc @julienxovates for information )

@julienXOvates Got it. I didn't get a chance to work on this over the weekend, so sometime this week, I'll just bounce the host and see if it comes back. Right now, while I can SSH into it, the admin console appears to be frozen and unresponsive (over iLO).

Interesting Maybe a way to create the vTPM in XO? Adding @julienxovates in the loop

@delacosta456 said: the pool host maximum limit is 3200% right right

@dinhngtu Thanks for the fast response, as always.

@gregbinsd let us know. If you do use my script. It pulls nodejs from NodeSource so it may not install the latest 24.15.0 tls. If you specific 24.15.0 it will install that version. If you need to change node version with my script use the rebuild option.

@Andrew Yeah but XOA is still using it hence my interest in aligning my XO-CE instance with XOA as close as possible.

Hello @tsukraw , normally your client should be able to bind the new license on their XOA. BTW, you talk about binding the license to a pool but an XOA license is bound to an XOA. I suggest your customer open a support ticket so we can help them with that issue.

While I was updating all the pools, a micro-update for 5 packages was released again. They come out every week now. Same issue with basic migration. Now it impossible.

Come on everyone! Click Here to vote to support HP IPMI info in XO!

Yes indeed, that's expected. XAPI affinity is on VM boot, not in the VM life. Then, it's the work of the load balancer.

Ping @Team-XO-Backend

@dinhngtu Yeah, I suspected that as well. So I inspected the SR and it showed connected to both hosts (at least in the XO UI - I didn't drop to the CLI to really confirm). By altering my workflow a bit and slowing down, I seem to have found the right "sweet spot" of delay and the issue hasn't resurfaced. Here's what I'm doing now, when I need to revert the snapshots of all three VMs: In the XO VM list, I select the three VMs and power them off at the same time. I then start with VM1 and eject the ISO, VM2 and eject the ISO, then VM3 and eject the ISO. By the time I circle back to VM1 for the next step, about 10-15 secs have elapsed. I then start with VM1 and revert the snapshot, and repeat the same on VM2 and VM3. By the time I circle back to VM1 for the next step, another 10-15 secs have elapsed. I re-attach the ISO to all three VMs in sequence. Another 10-15 secs elapse. I then start with VM1 and power all three VMs sequentially. The entire workflow takes about 30-45 secs, and I'm finding that by doing this, the issue hasn't resurfaced.