How to migrate XOA itself?
-
Hello,
So we have just stood up a new pool, and want/need to migrate our XOA to this new pool (the old one is being shutdown).What is the best way to migrate XOA to a new pool (preferably without needing to do this via CLI) ?
-
@TheNorthernLight Just export your configuration from the existing one, build XOA on this new pool and import the configuration.
-
@TheNorthernLight For this and other XO(A) downtimes I just have another XO instance running
Always nice to have a backup when the primary "fails" (only the primary does backups etc but the secondary has all the pools, storages and remotes configured). -
@manilx When i did this i used the xe CLI, you can also use xcp-ng center but with 8.3 you'll need to download a beta version linked on the xcp-ng center forum thread.
xe vm-migrate uuid=UUID_OF_XOA_VM remote-master=new_pool_master_IP remote-username=root remote-password=PASSWORD host-uuid=destination_host_uuid vdi:vdi_uuid=destination_sr_uuid vif:source_vif_uuid=destination_network_uuidDocs: https://docs.xenserver.com/en-us/citrix-hypervisor/command-line-interface.html#vm-migrate
-
@DustinB That seems fraught with failure. Have you ever done this successfully? From what I understand, restoring XOA meta data isn't that straight forward (but I've never done it, so I'm talking hearsay).
@manilx - This is why we run a separate host just for XOA (and a few other IT specific tools). But after almost 3 years, its time to upgrade our IT pool host, and it has all new networking so much easier to migrate then it is to run multiple copies.
However, after this re-structure of our host configurations, I might just do that, and stand up a second copy of XOA for this type of scenario. I've never run multiple XOA instances though, so I need to read up on the best way to do this.
-
@TheNorthernLight Backing up XOA config and restoring to another XOA instance couldn't be simpler!!
Not talking metadata backup but export/import of XOA settings. -
@TheNorthernLight said in How to migrate XOA itself?:
@DustinB That seems fraught with failure. Have you ever done this successfully? From what I understand, restoring XOA meta data isn't that straight forward (but I've never done it, so I'm talking hearsay).
Numerous times years over, you don't need to dispose of your existing installation once you have imported the system. The alternative is to do what @manilx said and to have a second running copy of XO.
@manilx - This is why we run a separate host just for XOA (and a few other IT specific tools). But after almost 3 years, its time to upgrade our IT pool host, and it has all new networking so much easier to migrate then it is to run multiple copies.
However, after this re-structure of our host configurations, I might just do that, and stand up a second copy of XOA for this type of scenario. I've never run multiple XOA instances though, so I need to read up on the best way to do this.
-
@manilx Right, it's quite literally, export config, import config.
Everything working on a new installation in a matter of moments.
-
@DustinB Luckily in this case, I dont need to kill the original, so if something goes wrong, I can always flip back. I guess I'll give this a try.
-
@DustinB Are the any downsides to having two XOA instances pointing at the same pool? Since the config itself is stored at the pool level im guessing theres no downside?
IE: Priimary XOA running in core DC and secondary XOA running at your DR site. Is it just a matter of adding the pool on the secondary XOA and it downloads the existing config or did you need to do a full export / import?
-
Every once in a while we have had the need to deploy a new XOA appliance and it is as simple as others have pointed out, just backup config, setup new XO(A) and then just import config.
Works like a charm, only thing we may have to do is to check the plugins configuration, but nothing else. -
@flakpyro said in How to migrate XOA itself?:
@DustinB Are the any downsides to having two XOA instances pointing at the same pool? Since the config itself is stored at the pool level im guessing theres no downside?
IE: Priimary XOA running in core DC and secondary XOA running at your DR site. Is it just a matter of adding the pool on the secondary XOA and it downloads the existing config or did you need to do a full export / import?
If you import your configuration, each XO instance will think they should be running the backups as far as I've noticed. If I have two instances running with the same configuration, I simply disable the backup jobs on one of them.
The config file is just an XML that contains your existing instance. You can import it to any new XO instance and have the same exact configuration.
