If I had my choice, Prevent Migration is more understandable.

Disable Migration, while it means the same thing, doesn't naturally come out of the English language.

@olivierlambert I was able to sort out the issue, it has to do with licensing and the fact that we aren't licensed to with "Live Migration" for this ESXi host.

Essentially this inquiry is solved.

@TechGrips While I can understand the desire to use removable USB as a Backup Repo, I would highly discourage it.

Managing and rotating USB drives is a pain, if they go to sleep, it's a pain, if they fail it's a pain, if you forget to rotate your drives, it's a pain.

I personally can understand the desire to do so, it's cheap and relatively affective if you can deal with these risks, however so is just using any NFS or SMB share and then having a replication script that could write to your USB, which you could then rotate. Separating your XCP-ng hosts, XO, and your backups is of critical importance because if you have any sort of server room environmental issues or failure, you're risking loosing everything.

XCP-ng and Xen Orchestra, while they do offer a ton of flexibility, there is obviously trades-offs to using less than ideal components, such as external USB drives as your primary backup repository.

If you really want to insist on using USB drives, you'll have to attach the drives to your host and then pass them through to your XO installation, which when you want to rotate those drives you'll have to update your Backup jobs within XO and confirm that your XO VM has the proper access to the drives. This seems like a lot of complexity for very little financial benefit.

Separately I think you're taking your own frustrations out on the community, because of a lack of understanding in the tooling that you testing in comparison to ESXi where you'd attach a USB drive directly, perform your backup, remove the disk and attach another.

I get that ESXi can make things "simple" but simple isn't always better.

HTH

The reason you wouldn't want to look at XO for this from a technical standpoint is because XO works at the hardware level of the hypervisor, dolling out resources to different VMs and creating backups.

You need to look at the content within a given VM and compare the file system difference from points A and B.

Only something that is operating within the file system would be able to readily tell you "Something has changed".

Odds are you have a user or several who are dumping files onto a share that they shouldn't be, or are replicating some cloud service to keep a copy on your server etc.

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

@yzgulec there really isn't any hard-fast rules to aligning CPU to vCPU. A Guest is going to need cores to operate no matter what.

If you're trying to min-max your CPU utilization for a given system, you might want to target the guest to use between 70-80% of it's vCPU all of the time.

This is all a part of system tuning and is always a shifting target, as CPU is shared among all VMs and DOM0.

As you increase the number of guests on a host, the CPU consumption will be increased, which means you may need to scale back on the vCPU a given VM has.

@stormi said in XSA-468: multiple Windows PV driver vulnerabilities - update now!:

Do others share this feeling and have this question after re-reading the whole announcement?

No it's pretty clear, update the drivers on everything as all versions are susceptible.

@olivierlambert I agree wholeheartedly with you on that. Keeping the system stock is best for support.

Separately, is there any planned work on officially integrating support for Uninterruptable Power Supplies and XCP-ng 8.3?

A question

• Have you clicked into the console screen before hitting F12?

You can disable all of the boot devices in the Advanced section of the VM, try disabling the HDD

Disable the Boot options if your system is making it past POST to quickly so you can get into the Guests BIOS.

@jasonnix said in A question for the creators of XO:

Hi @olivierlambert,
No, I'm not a bot. I asked it because I need your experiences. I want to make a panel for Xen.

So you know how to program with PHP and Ruby and not with Javascript, so the question is really "Why can't this be rewritten so I can help?"

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