@olivierlambert said:

I'm not sure it's a great idea, because even 64 hosts is huge in terms of VMs and fallout if you have a problem on your pool DB. Even if you drastically improve the current mechanism, the impact of a problem pool wide is far bigger with 64 hosts than 24 for example.

It's more than purely tech, it's also a tech design/choice.

Exactly, the failure domain just grows exponentially when going beyond a certain collective pool size.

I was doing some more research and I found a few possible choices that Tesco may have moved too, but don't want to detract from this forum here.

@olivierlambert said:

Even with existing customer with that many VMs or host, absolutely nobody will do a giant pool. And in the ROBO/edge world, it's mostly 2 or 3 machines per shop.

Even large DC deployments tend to use around 10 hosts per pool (a good sweetspot between convenience and fallout protection in case you have a problem on a pool).

Yeah, having 40K VMs or enough hosts to support that many VMs in a single pool would be career suicide to have a single giant pool. Especially since you can just setup cross pool replication.

@olivierlambert "Tesco's systems administrators have selected for the job, though the Ars Technica report says that the choice appears to be incompatible with both Veeam and Zerto, suggesting it's a lesser-known offering."

Did Tesco just drop VMWare for Xcp-ng ?? https://www.tomshardware.com/desktops/servers/tesco-uk-supermarket-chain-removes-40-000-servers-from-vmware-infrastructure-mass-exodus-continues-due-to-broadcoms-aggressive-subscription-model

@laszlobortel While I can understand "Upgrading not being an option" you're lift and shifting the workload (or at least have been attempting to do this to date).

Are you unable to build new and migrate data over to XCP-ng, while I could see this causing more work, lift and shifting is almost always a guaranteed way to cause headaches - like the ones you're experiencing.

That is why each service provider recommends building new if you can. At the same time that you're building new, you're updating which of course can cause issues - but continuing to run Rocky8 is only receiving security updates until 2029. Sure it has a few years left, but why not take the opportunity to upgrade?

@skipthompson81 Any updates that are due with XOA?

@skipthompson81 Are you using XOA or XOCE, what version and build numbers, is this the latest version of XCP-ng (at least 8.3), are there pending updates?

What is your backup remote details? NFS, SMB etc

@itservices Can you create a new backup job with just this VM and see if it's able to create a new chain?

@fdhabhar XO Lite isn't meant to be the complete tool to restore a VM from. It appears it does allow you to create a snapshot, but snapshots are the whole backup.

Is there a reason you're unable to use XO (Community or Appliance)?

@vlamincktr said:

@acebmxer I may just need to re-evaluate our backup strategy and adjust it so there is more time for the backups, I could also just run the daily delta's, the main issue is the weekly fulls that I run as a precaution, I'm always paranoid about something happening with the daily delta chain and having an unusable backup so i also pull dedicated weekly full backups which take a lot of time to run.

I've also considered running the full backups at different days to spread them out more, sounds like one of those is my best option rather than adding more cost/complexity.

I would absolutely change this backup plan, to running monthly full backups (weekly full backups are overkill for most).

The backup mechanism in XO has improved a ton (since launch). Without more detail, types of VMs, workloads etc it's really difficult for anyone to offer a perfect answer, but most people here would likely agree that weekly full's aren't a benefit here.

Changing the window on your backups is also an option as you mentioned, but that is only shifting when the work is being performed, not the type of work performed.

If you have a 1TB server and you're backing that up daily with delta's and weekly with full backups you're backing up something like 1300 GB every week (of course this depends on your delta data change).

Is the recommended approach for finding HCL equipment still to look at Citrix's HCL. Specifically looking at adding GPU's to our pool and want to confirm that we won't have any issues passing these through to our VMs for use in Kubernetes.

TIA

@BrantleyHobbs said:

Hi there!

I'm using XO from source.

I can't see how to apply patches to a host from the GUI in XO-6; it reports that there are patches, but there's no option to apply them. I have to switch to XO-5, or use the command line.

Has this made it into the UI yet and I'm just missing it?

(FWIW, this is a home lab, and I have only a single host in a single pool. I don't know if the GUI has safety checks to prevent patching a machine with running VM's.)

At the moment you can't this is a WIP. You'll swap over to the v5 interface and perform your patching there. Unless you wanted to login to your pool master, manually patch that and then reboot it, lastly manually patching your remaining hosts in the pool.

@Tristis-Oris said:

@DustinB but this is impossible scenario. CR requried a VM SR, not a backup one) weird option.

You're still replicating a VM to a storage repository.

Maybe the system will allow you to create a more flexible CR job using different hosts, rather than 1:1 . . . ?

@Pilow said:

@ph7

still not clear what it does
"one backup archive of each VM"... on first remote ? on second ? alternatively ?

You get to add multiple backup repo's to your XO instance, if your backup SR becomes full, XO starts using the second, third etc storage repo so you don't have to lift and shift your backups.

@flakpyro said:

My understanding is this should only be happening during backups, not a CR run though.

CR is a form of backup.

https://xen-orchestra.com/blog/xen-orchestra-6-2/

In the above blog posting this feature is explained that @ph7 referenced.

Another suggestion, collapse non-running VMs into a single group, rather than having them listed individually.

https://feedback.vates.tech/posts/50/collapse-non-running-vms-into-group

@john.c This is already viewable under each hosts in the pool.

@john.c said:

@DustinB said:

@olivierlambert https://feedback.vates.tech/posts/49/pool-view-rather-than-host-view

So you’re interested in having it a bit more like when using VMware vSphere while, regarding VMs, hosts and pools? That could work, but still need a hosts view for each member of the pool. In the host’s view it needs to be able to see, what VMs are running on it.

Also needs to be compatible with https://github.com/vatesfr/xen-orchestra/issues/9430. If not already synced with NetBox, the pool and hosts should be linked by UUID when synced. So in other words the structure needs to be pool is linked by UUID to host by its UUID and then the same for VMs. So the VMs are linked by UIID to the host UUID.

Nothing in my post would restrict the view to only seeing VMs within a specific Pool, the view should be flexible enough to shows VMs in a pool.

As it is now, you see all VMs that are running under a given host and then pool.

This in and of itself could become tedious to manage/dig through.

The potential remedy here would be to show all VMs in a pool, and on the given VM show the host where it's running.

matiasst created this issue in vatesfr/xen-orchestra

open Link VMs to Host Devices via UUID in NetBox Plugin #9430

@olivierlambert https://feedback.vates.tech/posts/49/pool-view-rather-than-host-view