Ping @thomas-dkmt for better doc clarity about it.

i also have slow speeds. Checked network connections works perfect. Checked disk performance is really good. But on migration speed is around 25mb/s.

It's not a problem with XO backups

Hi! ISO-SR over HBA/FC would be very nice, especially when migration form a SAN vmware-System to XCP-NG. One other thing is altering. Errors like "VM cannot be migrated" or similar should not be silent but should be very visible / even mailed to the admin. Another thing (could be cosmetical though) in my opinion is that a failed Rolling upgrade remains visible with a half fulled progress bar in the task-view. this is confusing.

@olivierlambert so strange though. i have it enabled on 4 pools, that didn't propagte on hosts. still VM boots up when not needed as explained on fist post of the thread. i'll try différent combinations to see what's really going on

@bleader Hopefully the palm print on my forehead isn't visible from where you are sitting. Of course the interface needs an IP address. In my defense, normally for something like this, I wouldn't put it on the bonded interface with all the trunked VLAN's for guest traffic (we don't give that one an IP) and it would go on the other bonded interface that isn't trunked and does get an IP, but these are test hosts and I didn't set up the other bond, so it is pulling double duty. I was able to set the IP's and get SDN working. Thanks!

Aha! I will move to prometheus in the future, but at the moment it is more basic. Thank you!

I had same problem, about last 2 weeks, but is is about Xen update, after apply last update, Backup of Windows VMs works again.

@Pilow said in Unable to copy template: something preventing you to patch thoses hosts ? yes.

@MajorP93 Hi, In the demo dashboard it is intended yes but these percentages are obtained by dividing the free memory by total memory so changing the dashboard to show GB/GiB should be quite straight forward. I've forgot to add to the initial post that there is a advanced dot md file that describes all the available metrics located in "xen-orchestra/docs/docs". Thanks.

@florent @fcgo the host that was queried (with host_ip/export_raw_vdi) will do the export from the shared SR, and will redirect the query to the host that can see the SR otherwise. So it's up to the XO/other orchestrators if they want to distribute the load here.

@dinhngtu Really appreciate the help finally got it working. In Debian 12 I was able to boot to it without issues even with 3GB (on both UEFI and BIO) but obviously not recommended for logs etc... Testing for Debian 13 now to see if there is something else affecting it and there is definitely weird issue with UEFI. BIOs boots up fine its the UEFI settings. This seem to affect the display as far as I can tell as I can ssh into the terminal without issue. I think part of the issue is to use only generic or genericcloud and avoid nocloud as its doesn't come with cloud-init install... They mention this on the site where we download it. Didn't quite understand until now...: azure: Optimized for the Microsoft Azure environment ec2: Optimized for the Amazon EC2 generic: Should run in any environment using cloud-init, for e.g. OpenStack, DigitalOcean and also on bare metal. genericcloud: Identical to generic but with a reduced set of hardware drivers in the kernel. If it does not work for your use case, you should use the generic images. nocloud: Does not run cloud-init and boots directly to a root prompt. Useful for local VM instantiation with tools like QEMU. (AVOID as it does not work with cloud init but it boot up so that was extremely deceiving...)

I am running NVIDIA P40s on a DELL R720/R730 and a NVIDIA A2000 12GB on a DELL Optiplex 9010 in my playlab. Getting the GPUs to be accessible for VMs was quite easy: shutdown the XCP-ng host, install the GPUs, start the host again, activate the GPU in the advanced settings of the host in the PCI Devices section (“Passthrough enabled”). The host will restart at this point after displaying a warning. That's it – the GPU can now be assigned to a VM in the VMs advanced settings. I do use the GPUs for AI workloads under Debian though, so your use case might vary.

An intake is created for review with XO team. Thanks for the feedback @puffymob !

@olivierlambert okay, understood. it is small minor cosmetic problem as of now. need to get you an access to our internal developped app, to show you the potential of sub-xoas ^^' almost out of alpha phase

Hi! See https://docs.xcp-ng.org/releases/release-8-3/#4k-native-disks and https://docs.xcp-ng.org/storage/#largeblock-sr Note that qcow2 format is supporting 4k natively, and it's in release candidate stage, maybe the right approach in a near future

Mentioning also @Team-Hypervisor-Kernel who now manages the drivers. Maybe it's related to https://github.com/xcp-ng-rpms/microsemi-aacraid/issues/2#issuecomment-3837183087 It looks like the switch to the vendor driver instead of the kernel built-in for 8.3 (initiated by XenServer, and that we followed at the time as it was probably made in order to support newer cards) was not without drawbacks. 0nelight created this issue in xcp-ng-rpms/microsemi-aacraid open Microsemi Adaptec Series-8 Card not working in XCP-NG 8.3 #2

@florent As it turns out, the job completed the next time it ran and this task went away, not sure why that first one failed but it seems to be OK for now. I will update this if I see this error again and be sure to include as many logs as I can. Thanks as always!

The thing is that it works very well and doesn't need fixes… I know, not usual right? It was so stable that we left it like that waiting for people coming for bugs and nothing happened… We'll cut a 1.0 in the next weeks/months.