XO Team group | XCP-ng and XO forum

florent

@henri9813 the warm mode is more manual by XO, and it can replicate from almost any version to any version, or any CPU to any CPU
the direct migration has some precondition : always migrate to te same or superior version. Live migration also add some condition on the CPU brand and generation

MathieuRA

@ElFritto Can you try this branch xo6/update-site-dashboard and check if that solve your issue?

florent

@dave.opc that's it

keep us updated on this

Bastien Nollet

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:

MathieuRA

Perfect, thanks.
We will fix the infinite loader for backups info soon

MathieuRA

I don't understand what's happening.
Could you try installing directly from the xen-orchestra GitHub repository? This would help us determine if the problem is with the ronivay installation script.
Could you also show us your xo server config?

florent

@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

florent

@dave.opc it should work . Add [NoBak] to one disk, transfer it, then remove the [NoBak] on the 2nd , restart the transfer => the first one will only transfer a delta , while the second disk will be transfered as full . If you put [NBak] on the first one for the second transfer, it will be handled as a disk deleted and will remove it on the replica

Note you will have the same issue if ( when ) you'll need to do a full backup later on, for example if there are any replication issue, or if you want to ensure your base copy is not corrupted later on

MathieuRA

Do you confirm that you are using an admin user?

XO Team

Posts

Member List