@Danp

Well.... yes... I was copying it, but I was also dropping a copy in the /etc/xo-server/config.toml directory as well....apparently i was trying to get ahead of the game.

As soon as I removed the /etc/xo-server/config.toml path and sample.config.toml file, everything loaded.

I have 2 other standalone XCP hosts...that do not exhibit the same symptoms.
Both are running older versions of XO.
The oldest has zero cleanup problems at all.
It's running commit 902f0

the 2nd is running commit 992d6 and seems to leave some snapshots behind.... but doesn't exhibit the VDI issue.

commit 290f5 looks like it may be the issue.

Never mind.... seems to have been something "stuck".

As soon as I deleted a couple of the VDI's..... everything took off and cleaned it self up.

I don't know if this is related to the "Snapshots not being removed after successful backup" issue that I posted a couple weeks ago.... but it seems like maybe it is.

I seem to be getting a bunch of "Unhealthy VDI's" ...and they are using up my storage space...
Any safe easy way to clean these all out ???

I can remove the leftover snapshots without issue....but I'm unsure how to proceed with cleaning up these VDI's ???

@Dude417

@olivierlambert

Full.

Hi All,

On 2 of my hosts (all are up to date on patches) my backup snapshots seem to hanging around.
ie: not being deleted / removed after successful backup.

On my 3rd host... everything seems to be working normally (?)

"In any case, XO is able to restore anything from the BR (backup repo or "remote") even on a completely brand new hosts with a complete different hardware, it's fully self contained and agnostic."

--- Understood. Thank you!

I was under the assumption that there may be issues with the XCP-NG host / backups etc... when UUID's are changed ? (recovering a lost host ) Or even restoring the XO config may be
not quite as easy as maybe it should be.... restoring a downed host

I understand that the referenced post (above) is a few years old....and that maybe things have changed regarding the procedure.
In my mind .... having an image available (during a high stress situation) that is already setup and ready to go seems like a good idea.

But I also see the beauty of being able to restore the XCP-NG host and config back to a system that may be installed on completely different hardware. That is pretty awesome.

Maybe I'll try a dry run in a lab situation to see which one feels better.

Thank you again for your time and consideration.

First , I apologize for the long question.

Is there any reason that I couldn't use something like Clonezilla or Rescuezilla to make a image of my XCP-NG host drive (where the actual hypervisor is installed) ?

Maybe once or twice a year, during some scheduled downtime, I make an image of the XCP-NG system volume.

My thoughts being:

• I now have an exact replica of my XCP-NG host drive and can be easily moved / copied / taken off site.
• In theory...if I have a complete loss of my local hardware (my XCP-NG host and the local SR on that physical host...due to fire / natural disaster/ whatever) I should be able to restore this image on like (or similar) hardware.
• Once the image is restored, the XCP-NG host should automatically connect to my backup location (remote NFS in my case) assuming it has a path and can "see" the remote, but will not see any local SR (because they don't exist anymore ).
• So I simply create a new local SR.
• I could then install a new XO instance (on the newly created local SR), and restore the XO config (metadata) from my backup location.
• at this point via XO I should be able to see all the backups and DR backups (in my backup location) of the VM's that were stored on the local SR (the one that no longer exists).
• XO will not be able to "see" any of the VM's that previously existed on the old (vanished) SR.
  *XO should be able to at least see and start the DR machines that are located in the backup location (yes?).
• I could then copy / move / save the disaster recovery machines back to the local SR at my own pace.

and now the questions (before I test this in a lab):
Does this make sense ?
Do you see any obvious issues where this falls apart?
Would I be able to "restore" VM's ? Or would they not restore because of the SR UUID change, or because the original VM no longer exists ?

The big benefit I see is that all the UUID's would remain the same just about everywhere (except the newly created SR??).
Most of the leg work would be done by XO, once the metadata config is restored.

Thank you for any input or ideas.

@julien-f

Awesome ! Thank you !
I'll try to test that today.

@Danp

That looks like xva format ...not ova ??? unless I am reading something wrong ??

VM export

xo-cli vm.export vm=a01667e0-8e29-49fc-a550-17be4226783c @=vm.xva

Or can I simply change the file extension ?? ( ie; @=vm.ova ) ??