To elaborate: it was already in progress, but delayed due to 1. the fact that I underestimated the impact (I thought we'd overwrite the file only when we'd modify it, not every update the package) and 2. lots of other priorities keeping the team busy. But it's clearly the reminder, and the help in better diagnosing it, that allowed to have it re-prioritized and (partly, we've mostly bought time to fix it properly, by simply avoiding to touch the file at all at the moment) fixed so fast.

Hello @nikade. I agree but this is my case. Try to migrate a running VM: error 500 Try to migrate an halted VM: error 500. Warm migrate: It's okay. I don't understand myself the difference except it doesn't transfer the "VM" but recreate the VM and import the VDI, ( so , the same things ), but there may be a light difference. I don't know how the "warm migration" works under the hood

Ouch. @andyhhp in case that trace rings a bell.

My current findings regarding this: https://github.com/xcp-ng-rpms/microsemi-aacraid/issues/2 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!

@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 @MathieuRA unfortunately, I won't be back until Sunday evening. I'll test it first thing Monday morning and then get back to you

@dave.opc that's it keep us updated on this

@florent said in vmware vm migration: @acebmxer yes after the first migration, XO knwo that the migration is incomplete and that you may want to finish it later. But if you start this VM direvtly , it will write some data, thus it won't be in sync anymore with the Vmware snapshot. Then XO won't be able to resume You can start a copy of the VM ( XO will handle it for you ) and delete the copy when you're done My advice is to migrate this VM to the right SR and then do the resume. But keep in mind that the V2V tool is intended to target only one SR, so migrate all they disk to the same SR, and select the right one when resuming the V2V. You can change the network after My previous migration was successful with no issues. Previously test vm was fresh install so no vmtools installed. But I did shut the vm down myself prior to starting the migration. VM boots no issues no prompts. This time I decided to follow the steps listed in the documentation as i have been following the changes and updates for the v2v migration. Following the steps as mention XO presented me with that prompt which was not mention in the documentation. As i was typing the post to gather my information it was then i noticed i did not select the proper destination SR and the appropriate nic/vlan for networking. So I noted that in the post. With the assumption i could correct that on the final migration. With that said the I guess the documentation should state - Start vm to test if boots, etc.. When prompted choose "Start a copy". When done shutdown vm and remove.

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:

Let me ping @Team-OS-Platform-Release

@Tristis-Oris the logic was directly ported over from C# version, so it does the same stuff what it filters there. It just toggles this search scope: QueryScope* TreeSearch::GetTreeSearchScope() { ObjectTypes types = Search::DefaultObjectTypes(); types |= ObjectTypes::Pool; SettingsManager& settings = SettingsManager::instance(); if (settings.getDefaultTemplatesVisible()) types |= ObjectTypes::DefaultTemplate; if (settings.getUserTemplatesVisible()) // these are custom types |= ObjectTypes::UserTemplate; if (settings.getLocalSRsVisible()) types |= ObjectTypes::LocalSR; return new QueryScope(types); } I assume it matches all user-defined templates, the defaults you see are "system defined" and part of xcp-ng .rpm packages. It's possible that this logic just wasn't ported correctly, I will look into it.

@busthead said in Windows 11 (Win11_25H2_English_x64.iso) Fails to Install: It appears I missed the key press to start setup Dont you know your are not suppose to blink when doing working. You might miss something Glad you figured it out.

Hi, Thanks for your feedback! Let me ping @bastien-nollet or @pdonias maybe

Hello All, This issue seem to completely go away on a older branch/tag if i build it from below for XO: xo-lite-v0.17.0 So the issue I would think is coming from the newer version of XO. Not sure best way to test this. So I am going back to an older commit. If anyone has any suggestion I can try helping as its an annoying issue.

Keep us posted, happy to hear from it!

I made a list of processes with a small bash script that I am attaching here [image: 1769612600385-screenshot-2026-01-28-alle-16.01.53.png]