When you migrate a VDI to another SR, its UUID is changed. So it's like a "new VDI".

However, there's an issue opened a while ago: https://github.com/vatesfr/xen-orchestra/issues/2896

We did not have a priority on this because not a lot of people asked for it.

I think it could be a good optional feature in a job.

snimmerjahn created this issue in vatesfr/xen-orchestra closed [Delta Backup] Avoid full export after VDI migrate #2896

It's in our documentation, please read https://xen-orchestra.com/docs/configuration.html#https

So far, I noticed this problem for three VMs. Each time I am trying to perform a backup with zstd compression through XO, the backup is marked as successful, but output XVA file is damaged (incomplete). The backup works fine for all other VMs, and I cannot pinpoint what is special about these faulty VMs.

Hi,

It failed because you changed the npm version manually. You can indeed re-deploy a fresh XOA, export the configuration and import it on the new one.

I'm not against exposing this in the UI, it might be not that difficult. However, more traction will obviously make it possible 🙂

No it's even better to have XOA. So I assume you are on latest and fully up to date?

Ping @julien-f

No problem, it happens.

@Danp super! lol that was exactly it...
and funny cause its the same plugin i was looking to have working! Cheers!!!

In fact, there's 2 different things:

Downloading and unpacking the updates (yum process). This won't change anything right now, because your current updated programs are likely running in memory (Xen, Linux, XAPI…) so only a reboot will make things changed: it's the current update button on the pool view. Evacuating the host, rebooting it to get all the new versions, and migrate back VMs to it (starting by the master)

Right now, 1. need to be triggered manually (you must do it otherwise it won't happen: bad if you forgot) but everything else is managed at all hosts of the pool at the same time (good).
And 2 is entirely manual.

So that's why I wrote this, to get 1. and 2. entirely automated while being safe and giving you reports: https://github.com/vatesfr/xen-orchestra/issues/5286

I have hopes we can deliver a first version (at least from the CLI) for this month release 🙂

olivierlambert created this issue in vatesfr/xen-orchestra open Scheduled Rolling pool updates (with reports) for XCP-ng #5286

There was a recent commit on Github dealing with NFS mounts. Suggest that you rebuild with the latest source and then try setting up the NFS storage again.

https://manpages.debian.org/testing/systemd/hostnamectl.1.en.html

hostnamectl set-hostname mymachine

If it's not, it's a bug 😛

@fluffy-bunny Use this to get your VBDs from each VM

xe vm-param-get param-name=VBDs uuid=<vm-uuid>

Then to get the name of each VDI file use this

xe vbd-param-get param-name=vdi-uuid uuid=<vbd-uuid>

But as olivier said, it is much easier to just use XO's disk view of the VM you want, then use the "copy" button to copy its VDI name.

Correct, I made changes to pfSense to be my DHCP and DNS Resolver, so had to make that change to the NFS Settings to reflect the Domain Name.

Thanks for your help!...

Seen this too late today but I will give it a whirl tomorrow! Will let know how it went.

@olivierlambert
I posted my issue building on FreeBSD here:
https://xcp-ng.org/forum/topic/3788/issue-with-building-xo-from-source-on-freebsd

Maybe its better so this doesn't go too offtopic. regarding this question its solved!

@Rocky

I'm a little confused I guess. I have a PIF section. There is nothing under my Private Network area.

Screen Shot 2020-10-30 at 6.48.50 PM.png

If migration failed, there's a reason. It's usually stable.

Obviously, because your hosts weren't in the pool, a different CPU model can be the problem (they are automatically adapted if they are in the same pool).

I don't this we support UFS right now.

If I remember correctly, we got:

FAT NTFS ext xfs LVM based

That updated my Netdata package from 1.23 to 1.26, and now the plugin is working. Thanks!