@bvitnik Thanks for giving more details. I will give a try with each of them (netplan, ..etc)

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

One more question! How can I add the contents of that field to the output? This curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?filter=other:XenCenter.CustomFields.export_vga:"*"&fields=name_label,other:XenCenter.CustomFields.export_vga" doesn't work. I did double check that multiple fields are comma delimited, I can set fields to fields=name_label,power_state I'm assuming this is something weird about properly quoting and escaping different parts of the call. For example, thee above example is actually passing three chunks because of that quoted * within the quotes. But if I try to make it make more sense it stops working at all. OK, this works: curl -k -b authenticationToken=$tk "https://xoa.pc.scharp.org/rest/v0/vms?filter=other:XenCenter.CustomFields.export_vga:*&fields=name_label,other:XenCenter.CustomFields.export_vga,power_state" and returns the name and power state but not the custom field OK, I didn't expect different results but I get the same behavior in python using the requests module.

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 will try it ASAP. Thanks for the hint!

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

Hi @champagnecharly , On the XO side, it seems that this PCI has an empty string ID, which doesn't enable us to delete it. We'll have to do some tests to find out how to prevent that. We might have trouble reproducing the issue, so would you mind helping us with the tests? You would need to add this piece of code on file xo-server/dist/xapi-object-to-xo.mjs before the line that start with if (isHvm) { (that should be near line 475) if ((_vm$attachedPcis = vm.attachedPcis) !== null && _vm$attachedPcis !== void 0 && _vm$attachedPcis.includes('')) { warn('Empty string PCI id:', otherConfig.pci); } then restart xo-server and look at the output of journalctl, there should be some lines looking like: 2026-01-30T09:26:17.763Z xo:server:xapi-objects-to-xo WARN Empty string PCI id:

@pdonias https://docs.xen-orchestra.com/users [...] Operator An operator can make everyday operations on assigned objects. For example, on a VM: eject a CD insert a CD (if he can view the ISO storage repository) start, restart, shutdown, suspend/resume it All other operations are forbidden. [...] As I understand it (I may be mistaken), changing the "Rate Limit" is already a configuration change and should not be available to an Operator.

I don't think stop will remove it, probably better to yum remove it. For Openmetrics, check: https://docs.xen-orchestra.com/advanced#openmetrics--prometheus-integration I switched our own production to that, so far it looks promising.

If I remember some previous discussions, EVE-ng uses some features that doesn't work in nested mode with Xen.

We are not energy efficiency experts, while EasyVirt people are. I think they already have some stuff and it might be just a matter of plumbing.

Hi @Kptainflintt, I don't think this is related to XO6, but probably to this PR: https://github.com/vatesfr/xen-orchestra/pull/9231 VDIs with snapshot_of: <something> are now recognized as snapshots spacotte-vates opened this pull request in vatesfr/xen-orchestra closed fix(xo-server): improve handling of xapi snapshots #9231

@acebmxer It's not pretty, but its failsafe. The proceedure looked like this in our case: Disable HA in the "old pool" Put a host in the "old pool" into maintenance mode Reinstall that host and connect it to XOA and then patch it Create a "new pool" from that host Create a new LUN or NFS share in the SAN for "new pool" and attach it to "new pool" Live migrate VM's over from "old pool" to "new pool" Once you've freed up another host you repeate step 2 and 3 and then join that host to "new pool". It is important that you patch it before joining it to the pool, that is done by going to Settings -> Servers in XOA and connect to it manually. And then just continue untill you're done. Live migration is pretty reliable now days, so this works pretty good and since we had 10G network its not taking as long as it used to do with 1G network. We did this after a major incident on our primary production site where 2 out of 4 hosts in a pool "suddenly" lost their NIC's after updating them. Since then we never updated the pools again. Standalone hosts are fine tho, they never did this. Luckily we had 2 other pools where we could migrate the VM's to, but we couldn't realy trust the updating after that.

I provided some feedback.

@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

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

Worth asking @Team-OS-Platform-Release

@florent I think you meant it was locking the xoa via .tar.gz but not via .zip which seemed to be the case Yeah I just decompressed the restored .zip and checked number of files and size via ncdu, result: "Total disk usage: 194,5 MiB Apparent size: 193,1 MiB Items: 613" In case I can provide more information for investigating this issue, please let me know. Thanks and best regards