@probain Not that this is an answer, but what happens if you uncheck the deletion box, and delete them manually?

@nvs Hi there, we had a similar issue with on our 5900x boxes. We have about a twenty of these and they have been generally greats hosts for xcp loads. However, one of them was constantly rebooting. While testing the ram the temp jumped to 90/90. They are running in 1U boxes so I expect heat but this seemed silly. We ramped the fans to max but this did not help. We then used bios to drop down various cpu boost profiles and gadgets to lower the heat and re-applied paste to cpu.. so far so good.

I know this is old but I had a similar issue. In the end I told dracut NOT to reassemble my raid array which allowed the system to boot perfectly after. I have no idea why it tries to assemble the same array two but on the second seems to be important

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.

Okay so it's maybe a bug that's easy to reproduce on our side, with a retention of 1 or 2. Let me ping @florent Thanks for your report!

@olivierlambert I was able to do it via api

@olivierlambert Thank you, I'm hoping to setup a test server for that out this weekend (or sooner) and will update. Amazing to see this level of support and enjoy any time you join the various YouTube channels, especially @lawrencesystems Vlog Thursday or Live Streams.

@Pilow tags can work and the path to them is much more succinct. Thanks!

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

What is the purpose of this discussion? You did create this thread, I think you would know what's the purpose of this discussion Have you asked VEEAM for a solution, because it seems more VEEAM-related question after all I have no idea what it means regarding "replication is not possible for this Oracle point via VEEAM". Remember we aren't from VEEAM in here, so you should explain more precisely what do you expect from us to do despite it seems to be a VEEAM limitation?

Something to document @thomas-dkmt

[image: 1770204922255-7ec89d01-64e4-47c6-a800-e4de50a56e38-grafik.png] This is the RAM usage of my XO CE instance (Debian 13, Node 24, XO commit fa110ed9c92acf03447f5ee3f309ef6861a4a0d4 / "feat: release 6.1.0") Metrics are exported via XO openmetrics plugin. At the spots in the graph where my XO CE instance used around 2GB of RAM it was freshly restarted. Between 31.01. and 03.02. you can see the RAM usage climbing and climbing until my backup jobs went into "interrupted" status on 03.02. due to Node JS heap issue as described in my error report in post https://xcp-ng.org/forum/post/102160.

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

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