@Pilow Which Node JS version does your XO CE instance use? Could you possibly also check what Node JS version your XOA uses? As discussed in this thread maybe there are some RAM management differences when comparing XO on different Node JS versions. I would also be a big fan of Vates recommending (in documentation) XO CE users to use the exact same Node JS version as XOA uses... I feel like that would streamline things. Otherwise it feels like us XO CE users are "beta testers". //EDIT: @pilow also maybe the totally different RAM usage seen in your screenshots might be related to the XO CE not doing any backup jobs? You mentioned that you use XO CE purely as a read-only fallback instance. During my personal tests it looked like the RAM hogging is related to backup jobs and RAM is not being freed after backups finished.

Good morning, So I unfortunately had to re-open this issue. I thought this was fixed with a new PSU. However the reboots did show up again some time later. I upgraded XCP-NG meanwhile to the latest stable 8.3.0 and ran all the patches. I was curious if it would still show this behaviour afterwards. I also tested running different VMs on that machine, and after some time I am fairly confident to say now that running one particular VM seems to cause these sudden reboots of the host: Its a VM with 2 CPUs, 8 GiB of RAM, running Ubuntu 22.04 with MongoDB. It has a 20 GiB OS partition and, possibly the relevant clue; a 20TB raw disk passed through into the VM (15 TiB partition). I did a lot of testing the last weeks without that VM (MongoDB) writing to that raw disk, and had no reboots. Yesterday I configured that MongoDB VM to continously add data again to that raw disk and since I've had 2 reboots in just a single day again. The good news is that I should be able to replicate the issue now. Could someone give me pointers what I could still try to figure out what is exactly going wrong/how I can go about fixing this? Thanks!

@randyrue on our side, we do not use custom fields, but TAGs. working well. depends on the number of custom fields you manage, and perhaps not usable because you need field:value ? but nested tags could do the trick : field=value [image: 1770190720889-99027821-448b-415e-ba89-321260247f73-image.png]

@dinhngtu said in XCP-ng Windows PV tools announcements: Hello all, The XCP-ng Standard VGA Display Driver for Windows v0.1.29.2216 has been released https://github.com/xcp-ng/win-xstdvga This driver provides high-resolution consoles and resolution switching for Windows VMs running on the XCP-ng hypervisor. This is a beta release. This driver will eventually be integrated into the main Windows PV tools package. Driver pulled for bug fixes. Will come back soon Test on windows 11 vm no issues to report.

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.

@Danp thank you for the help. I have looked at all vhd in my disk and they are all good as per vhd-tool check. Regarding the logs in xensource logs the first error is showing up few mins after I trigger the export. #!/bin/bash # Script to check all VHD files in the current directory using vhd-tool set +e # Don't exit on error total=0 failed=0 echo "Checking VHD files..." echo "" # Loop through all .vhd files in current directory for vhd_file in *.vhd; do # Skip if no .vhd files found [ -e "$vhd_file" ] || continue ((total++)) # Run vhd-tool check if vhd-tool check "$vhd_file" > /dev/null 2>&1; then echo "PASS: $vhd_file" else echo "FAIL: $vhd_file" ((failed++)) fi done # Report echo "" echo "====================" echo "Total: $total" echo "Failed: $failed" echo "====================" [ $failed -eq 0 ] && exit 0 || exit 1 /checkvhd.sh Checking VHD files... PASS: 014e122e-7908-4566-be52-31fc40ea6042.vhd PASS: 054f3177-e40b-4c87-86c6-88ac9db3edfe.vhd PASS: 154c4dd3-651d-404b-8df0-e85a07aa5bf6.vhd PASS: 16f68c2a-74d7-4698-8276-56bdc686e161.vhd PASS: 18b4a57f-3c77-42da-973c-d136375878da.vhd PASS: 1a129b44-a562-4555-8785-2bfaa1f98455.vhd PASS: 1e62a336-bb27-40f0-8da5-1f53cbeeee83.vhd PASS: 24b6ede5-b698-4a9d-acb1-a4898d78cf8c.vhd PASS: 24b82a29-9fe2-47af-a68b-f36a73b34624.vhd PASS: 2d8b1375-4fc8-46eb-b1f6-2d887e37602c.vhd PASS: 2e3897fb-7d45-4098-9956-d985636d9a12.vhd PASS: 3165bf7b-ca6f-4a30-b33d-bda31e2c67ab.vhd PASS: 31832728-0001-407d-85f6-0de340e2dbda.vhd PASS: 32f501b3-47df-4730-824b-f9e297e9d12c.vhd PASS: 346c5bf0-6635-4f1b-af32-fc9f8fac5088.vhd PASS: 3a7f68ce-b342-4d03-878f-956e74074b6a.vhd PASS: 406f2750-fea7-4389-920f-0b080335284f.vhd PASS: 4156d2ea-d39d-436d-b89f-06ad64949c53.vhd PASS: 475b16f8-f1c0-40b6-b181-99f83f14dd73.vhd PASS: 52656fa5-d418-45e0-9e65-07a450af2476.vhd PASS: 69042c99-b0a3-47ab-8c2b-48303c4cc6bc.vhd PASS: 6a79914e-67e0-4ac9-b93e-2e393aaa7b97.vhd PASS: 6b0919bb-7d0a-4036-a833-0313476a11a3.vhd PASS: 7e2fc00c-7208-4132-aa4a-7db818c7a94b.vhd PASS: 824af8d0-112b-479b-b474-6e5a26e0d8b2.vhd PASS: 8f6d6a7c-5390-43bd-b0b5-55f8e681453a.vhd PASS: 94453b92-3a69-416b-9c08-9f0b91b2aee1.vhd PASS: 947ad175-06a7-4881-8725-aba36d2cda66.vhd PASS: 97e577dc-b0be-4990-8e06-c0c4333aef82.vhd PASS: 9889a738-cfd4-447d-962a-8fd88222d8ab.vhd PASS: 9c93fa78-4b17-41b1-b794-8bfa165ed4b4.vhd PASS: a3408bda-9c26-4333-b535-3a008109b98c.vhd PASS: a3c69ec6-f56e-4d25-ba71-023a38eef8e3.vhd PASS: a8c45c4c-8925-41a3-a78d-c30d6e20c261.vhd PASS: b119ad26-f0dc-4965-b726-9dc3fc815130.vhd PASS: b12002da-56b6-451c-ad4d-a6c16a79fc12.vhd PASS: b24f9236-6b68-4214-812d-9e98994467aa.vhd PASS: b34f20b8-6681-42e9-b234-116989286699.vhd PASS: b5ff8f04-0ace-4b23-9f0b-7a6c5328bef5.vhd PASS: b932bc63-a47d-49cb-9d28-a57ad61e7ad9.vhd PASS: be06df0b-cbb7-4dfe-8eaf-697de4d8850b.vhd PASS: cb88a496-8c80-41e2-b3de-055916a3a32c.vhd PASS: ce66b785-5b1b-43c8-9ece-dc456508014c.vhd PASS: ddb84192-3e35-4541-86da-d4326a6bbea7.vhd PASS: de27f27e-65b8-42d3-929f-f34f0544149a.vhd PASS: e054e9da-08e7-40b1-8c55-0fd2ae97ee5f.vhd PASS: e449742e-5007-4be6-89c0-2529d00dbf28.vhd PASS: f0ee695e-dcb4-49e6-ac17-4a64f65998a6.vhd PASS: f20e6bb0-4cba-4030-87fc-ddbaca262169.vhd PASS: f28a0554-6530-4055-a67e-d970ab1c4cc1.vhd PASS: f5dd3ee4-7006-43fc-8254-98eb45505639.vhd ==================== Total: 51 Failed: 0 ==================== I'll give another export try to see if it works this time. best.

@markxc I don't think this is possible yet with the REST API. However, you should be able to do it using xo-cli: xo-cli vm.setBootOrder vm=<string> order=<string>

What is the purpose of this discussion? Could this feature integrate XCP-ng? We are looking for a new virtualization solution. Oracle is a bottleneck for backups. We tested the backup with the Veeam agent, which appears to be successful. However, replication is not possible for this Oracle point via Veeam.

Hello Hope this help here is how I manage to configure GPU Passthrough. In my case I have follow the documentation on XCP-ng website : https://docs.xcp-ng.org/compute/ To sum up with XOA 8.3 here is what I did: ssh to XCP host, to identify the GPU PCI and run lspci to find my GPU. [root@xen ~]# lspci ... 0f:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1) Then disable the GPU for being used by XCP-ng itself( Dom0) using the XCP-ng uuid [root@xen ~]# xe pci-list uuid ( RO) : 7970825f-dd1c-c270-93a3-6761f00e1362 vendor-name ( RO): NVIDIA Corporation device-name ( RO): GA102 [GeForce RTX 3090] pci-id ( RO): 0000:0f:00.0 xe pci-disable-dom0-access uuid=<pci uuid> 3 reboot the XCP-ng host 4 Then from XOA attached the PCI related to my GPU to my guest VM. [image: 1770098359041-4dcb36ff-b29c-4d0b-b113-127243928dd6-image-resized.png] [image: 1770098407490-3f29792e-154f-40fc-b554-323d8ef87e52-image.png] [image: 1770098436148-7208a3ff-68e2-4c50-9dc8-2edde9ac8d76-image-resized.png] 5 install official Nvidia drivers ( closed source ) and have then the card available in the guest. [image: 1770098585851-9bcbea25-b83b-4a26-a085-b58236c83f84-image.png] [image: 1770098624052-88f35aba-bd75-4da6-9cbf-d62bb8994ef7-image.png] What I didn't do is adding a vGPU in the guest configuration: [image: 1770098900399-63b2a458-9758-40d1-9515-48b5cd4615ea-image.png] I did it some times ago, also I don't recall having to do any specific configuration in the Bios to make this work. PS: I have an issue, I don't have output to the Display port or HDMI of this video card, which is not a blocker for me as that's not my immediate needs. Best.

@Danp will try it ASAP. Thanks for the hint!

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

@henri9813 Ahh alright, I understand now! Thanks for clarifying.

I just want to add that I am seeing the same issue with Ubuntu 24.04.3. Creating a VM does work, but it crashes immediately when trying to start it for setup. I have not yet tried the approach of starting with 24.04(.00) and then upgrading to the lastest version due to lack of time. We are still using XCP-NG 8.2.1 on the server in question. If an upgrade to 8.3 solves the issue, please let us know. Reading the thread, it appears to have the same problem, though. Processor is an AMD Ryzen 9 3900X. We have not had any other issues with the system and it's been running for a few years.

@dinhngtu I think it just have been a bad migration or the Win 11 Template did other things to the windows 10 os. Since new test vm did not show the time issues, and a fresh migration of the vim with correct template selected did not have the issues either. I dont know but maybe there is a way to put detect the correct VM template or make note. I didnt think using the win 11 template would have caused issues since using the "wrong" template on vm creation does not have the same effect.

@Tristis-Oris There are many features missing since it's alpha now, but you can open bug tracker request on github if you want to keep track of progress for this particular feature.

@wilsonqanda Make sure to turn off "Network" in boot order. You might also want to increase the VM's root disk size when creating it. Here's a full cloud config that I used (except the ssh keys): #cloud-config hostname: {name} ssh_authorized_keys: - ssh-rsa ... disable_root: false apt: sources: xen-guest-agent: filename: xen-guest-agent.list source: deb [trusted=yes] https://gitlab.com/api/v4/projects/xen-project%252Fxen-guest-agent/packages/generic/deb-amd64/ release/ append: false packages: - xen-guest-agent

@MathieuRA As announced, I have now installed branch xo6/update-site-dashboard and it seems to be working. It no longer loads endlessly and shows me that I haven't configured anything yet Thank you very much!