@McHenry hi

you need to call xe vm-import filename=/path/to/file.xva

It seems that it is possible to clean old isos manually, via the command line, as explained in this forum post: https://xcp-ng.org/forum/post/15703

To my knowledge these files are backups when installing new versions of the tools during rpm updates. They do not necessarily take up space or this is managed directly during updates.

Nothing to clean here.

I have the same thing on my test servers (and sometimes even more files than that) and I have never taken care of it.

Do you have a space problem on this SR to want to delete them?

@stevewest15 Thx for SMlog. I don't see anything suspicious

XCP-ng doesn't know it's the same SR. So either you added the host in the pool and just do a regular live migration without any data move (and then eject the old host), or if the hardware is very different (not same CPU vendor or NIC numbers too different), then warm migration is likely the easiest way.

Alternative, if there's no complex VDI chain, you could move the VHD file to the right folder. But this can be tricky and dangerous if you don't know exactly what you are doing.

Ping @gduperrey

Because remove an ISO on a ISO SR is not supported. Rescan the SR ("refresh" icon in the action bar on top right) and see if they are still displayed.

In the log of the source host I see Oct 14 20:09:06 XCP25 xapi: [error||3 ||storage_migrate] Tapdisk mirroring has failed
Can you also provide /var/log/SMlog that corresponds to the migration time. As it was yesterday maybe you should look in /var/log/SMlog.1
Thx

Hi,

This is not an XO issue, but a "normal" problem when you try to move a big VM: a live storage migration means the blocks has to be replicated to the other side while the VM is running. However, if you write a bit faster than the mirror, it will fail. For such large VMs, I would go for warm migration.

We had to reorg a bit the team, with the creation of an internal devops team. We hope to get some cool news in the following months