Upgrading XCP-ng host hardware

dartec

Hi All,

I am new to XCP-ng.
I initially installed XCP-ng onto a machine with an AMD X470 motherbard and 250GB SSD.
I have some storage connected by SR via NFS mounts.
I want to upgrade the host to an AMD 570 motherboard, a different CPU and a 500GB NVME (to replace the SSD).
What is the preferred way to do this?

Could I just take the SSD and transplant it across to the new machine and then (somehow?) replace the SSD with the NVME?
Please that note my setup is just 1 host (not clustered).

Thanks in advance.

olivierlambert

At first sight, I would probably install a fresh XCP-ng on the other host, backup the pool metadata on the old one, shutdown that old host, and restore those metadata on the new one.

dartec

@olivierlambert Thank you for this. So on the new host, I assume that I would need to set up all the SR's before restoring the metadata?

From your reply this is how I understand it.

Build new host (as a new installation)
Backup metadata on old host and then shut it down.
Configure SR's on new host (the same as they were on the old host).
Restore metatdata backup on new host.
I should be good to go ..

Have I go the steps right?

olivierlambert

You shouldn't configure anything. Metadata restore should reconnect to every existing SRs and such.

dartec

@olivierlambert Okay ... But to restore your metadata backup, surely you need to connect to a SR (where the backup is stored) or am I misunderstanding. I have never done this type of restore before.
How would you restore the backup? From the command line or XCP-ng Centre?

dartec

@dartec Hi All. I am still trying to work this out.
Where should I back up the metadata to? My backup SR is on a NFS share.
I don't understand how I can restore the metadata from a backup without adding the SR.
Am I missing something here?
I assume that the best way to restore the metadata via xsconsole on the new machine?

TIA

olivierlambert

In Xen Orchestra, metadata backup is done in the backup repository (BR, also called "remote").

To restore, after you installed your fresh XCP-ng, connect to it in Xen Orchestra, and then go to "Restore"/"Metadata" and select the fresh connected XCP-ng pool/host, and validate. Then, the host will just get all the metadata back and reconnect to all SRs and so on.

dartec

@olivierlambert Thank you.
Now I think I see my problem .... my Xen Orchestra instance is a VM on that host ...
I assume it would be best to have the XO instance on another machine?

olivierlambert

It doesn't matter: if your XO dies, you can re-import a fresh one and reconnect to the backup repo, and restore metadata.

sshughes

@olivierlambert Trying to understand this. The way I read it, dartec wants to restore a single host pool to a new host having new (different) motherboard, and you've said to do a fresh install on new host and restore from a pool metadata backup made on the original host. Yet in a response to 6852 you say "Metadata restore is meant to restore on a similar host. Alternatively, restore the real VM backups via XO."
I get it, I looked at the metadata backup and it contains lot of hardware details, so expect it would be challenging at best.
Actually, I'd be happy if there was documentation to attach a new host (original is dead) to an existing SR, whether internal (pulled from dead host) or network, and restore/recreate/import the VMs from the SR (and earlier metabackups). Sorry for posting similar to multiple threads, but it seems I'm seeing two different answers, and perhpas that planned development will soon make it a feature.

MTTUPM

@sshughes My understanding of the system so far (but take that with a grain of salt, in real life I'm sort of an accountant who's only larp'ing as a sysadmin here): the system is not meant to 'run on a single host and when it dies we replace it'.

It's meant to run on three identical hosts which never all die at the same time (except for some GBU hitting their building). Therefore there is no focus on 'let's reconnect new hardware to existing SR and fire up the VMs stored on that SR'.

After planning accordingly, I can live with that. Planning accordingly in my case means: 'well, if my single host dies (running two or three isn't worth it for me), I'll take a day of down time to restore from backups.'