Are you using EXT or LVM?
I've seen this as well with large VM's and not enough free space on the source host, the only solution is to either free up some space or do an offline copy. Migration wont work, so copy is your only option.

@florent I'll send you a link in DM, hope it helps with something.
If not, it wasn't too much of an effort, thanks for your time so far

Thanks @florent - I can see some of the export logs, but not this particular window-vm, unfortunately. Probably because its too far back in time:

Dec 27 21:33:19 xoa xo-server[845]: 2025-12-27T21:33:19.667Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-serverG5cHF7
Dec 27 21:36:22 xoa xo-server[845]: 2025-12-27T21:36:22.559Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] Windows Server 2022 veeam2.iextreme.org/Windows Server 2022 veeam2.iextreme.org-000005.vmdk are in /tmp/xo-serverqv0XVK
Dec 28 00:32:35 xoa xo-server[845]: 2025-12-28T00:32:35.287Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-serverfqb8lP
Dec 28 15:28:09 xoa xo-server[845]: 2025-12-28T15:28:09.050Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-serverxcV6N7
Dec 29 20:13:27 xoa xo-server[845]: 2025-12-29T20:13:27.226Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-servermnF0TD

The observium VM worked at last, but I had to give it 4 tries before it actually worked.

Edit: Right now all my important VM's have been imported, so I don't think we have to spend anymore time on this, unless you want the logs for the observium import.

@Danp Yeah? How?
Let me know if you want me to grab some logs for you guys, if it's still interesting.

@florent Oh shoot! So only during the actual vmware import? I guess they're gone now then
Sorry I couldn't be of more help!

@florent Sorry to dissapoint you
Can you remind me where the vmware-import logs are stored on the XO machine? I can see if I still have them for you, it could be an alignment issue.

@florent it was 2 windows vm's, both with 100gb but not even 50% filled.

Edit: All Linux VM's worked tho.

Got most of them working, except 2 of the bigger ones.

@irtaza9 it scans all the VDI's on the SR to see if something has changed, if there's a need for coalesce and so on.
I dont think it will be a big issue if you increase the auto-scan-interval value to lets say 5 minutes (300 seconds), but do remember, that everything regarding the VDI's on the SR will take up to 5 minutes to update, as well as triggering coalesce after removing snapshots.

@acebmxer It's not pretty, but its failsafe. The proceedure looked like this in our case:

1. Disable HA in the "old pool"
2. Put a host in the "old pool" into maintenance mode
3. Reinstall that host and connect it to XOA and then patch it
4. Create a "new pool" from that host
5. Create a new LUN or NFS share in the SAN for "new pool" and attach it to "new pool"
6. Live migrate VM's over from "old pool" to "new pool"
7. 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.

@acebmxer did it ever finish? Did it work or was the vm shutdown'd?

This is a classic issue with XAPI, once you have hosts in a pool and the slave cannot reach the master it will go crazy. Never seen this issue with standalone hosts tho.

We usually had this issue when upgrading xenserver, so we simply stopped doing that and then never had any issues. We went to "new" versions by simply standing up a new pool and migrate all the vm's over to it

I have no clue, I usually back it up with XO, its the one called "XO config & pool metadata backup" and only had to restore it once.

@vague said in Bitten by XSA-474:

starting up database engine D:2a59ed50ccb5 failed with exception Xmlm.Error(2:317874, "malformed character stream")

My guess is that your xapi database has been corrupted, if you dont have a backup this will be a rough one.

To add some content I'll summarize what you wrote on IRC:

1. You got an error, it was not resolved.
2. You then decided to start upgrading your xcp installation
3. Now the database is corrupt, not sure it it was already or if it happend in step 2.

Cool, thnx for the info!

@marcoi said in How to Setup IPMI in XO:

curious how does this work, dont you need to put in a username and password/IP address for ipmi details. I havent looked at docs or tried this out, just wondering. I think on ESXI i had to setup the ipmi with such details before i could issue power on etc.

I am also curious, since I asume authentication would be required before you're allowed to read or write data from iDRAC, we have a read-only "statsuser" to poll from iDRAC with Observium.

But maybe there is some kind of "special" integrated pass-through authentication done since the ipmitool is being executed from the same host.

@florent no im using EXT local SR. I tried downloading a VMDK and it worked fine, so not really sure whats going on.

I also tried from an esxi 8 host within the same network, same thing, I could also download a vmdk from it.

I just migrated from 2x vmware vsan hosts and 1x vmware standalone to xcp-ng in my lab and every migration resulted in a stop of the source vm. It's not a big deal for me in our lab, but I had major issues with some VM's never "finished" the migration.

Xen Orchestra, commit b89c2
Master, commit b89c2

I noticed that after the task has timed out, the VM that was migrated is often able to start, even tho it was not "finished". Is this expected?

I just learned something new, thats awesome

@bvitnik Thanks for explaining, I was always under the impression that dom0 was the "host" so to say.