@olivierlambert

Understood

@olivierlambert

@olivierlambert said in XO and XCP-ng pricing:

if you’re working with a nonprofit, I’d really recommend reaching out to our sales team directly.

--- K-12 education as well??
Small school districts are getting beat up by Broadcom too. Most small districts would easily fall at or under the 3/4 host limit.

Lovin' this.... thank you for picking it up. Great tool to have.

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 ) ??

I know I can export VM's from the XO GUI to OVA format.
(and it works fine)

Is there any way to export VM's to OVA format using the command line ??
(either on XCP or XO)

I can find plenty of examples of exporting to the XVA format, but I can't seem to find much on exporting to the OVA format.

@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.

@Danp

root@XO-SourceBuild:/home/xo/xen-orchestra/packages/xo-server# yarn start
yarn run v1.22.22
$ node dist/cli.mjs
✖ EISDIR: illegal operation on a directory, read
Error: EISDIR: illegal operation on a directory, read
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
root@XO-SourceBuild:/home/xo/xen-orchestra/packages/xo-server# node -v
v18.20.2
root@XO-SourceBuild:/home/xo/xen-orchestra/packages/xo-server#

@Danp
V20.12.2

Debian 11

Following directions from :

https://xen-orchestra.com/docs/installation.html#from-the-sources

Everything looks fine until I get to "yarn start".
then :

xo@XO-Source:~/xen-orchestra/packages/xo-server$ yarn start
yarn run v1.22.22
$ node dist/cli.mjs
✖ EISDIR: illegal operation on a directory, read
Error: EISDIR: illegal operation on a directory, read
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
xo@XO-Source:~/xen-orchestra/packages/xo-server$

I have tried installing as both a limited user "xo", and as root... same error.
It appears to be a error where a directory is found rather that a file...
Any ideas what log files / config files I should be looking at ???

@olivierlambert
SMH .... Ok ...just found the import config under settings >XO Config... sheesh.... how did I miss that.

'Do an XO metadata backup to your backup repository. In case of losing XO, add a new backup repo which is the previous one, and XO will find both all XO metadata ready to restore and previous backup"

I wasn't doing the metadata backup to the SR.... I'll have to step back and try that again.
Thank you for your time !

@olivierlambert

Ahhh..... so under by backups I need to make sure that the pools metadata is backed up. Probably at the same time as the actual DR files for the VM's. That makes sense now.

So after a new host is setup, and a clean XO setup.... how / where do I restore the metadata ??
the docs' seems to assume that I have access to it.... when a clean XO install will probably not ?
ie: A new XO instance will not show any historical backups of the metadata to restore ... yes ?

The obvious answerer is "restore your XO config" then you can see the metadata backups...
which puts me in the same situation.... how do I restore the XO config on a new clean install???

@olivierlambert said in DR worst case planning:

you can simply restore all your VMs via Xen Orchestra.
--- assuming that Xen Orchestra wasn't on that same host. Correct ?