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.

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

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

@lakpyro said in How to migrate XOA itself?:

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

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

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

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

Hi @livierlambert,
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?"

For laughs I am testing with a VM that is powered off and its going, albeit slowly (likely due to a 10FDx port on the ESXi host).

@laidypus You can configure the disk within the guest OS to match whatever formatting you want. I would suspect the performance gains would be included as well, but you'd have to test and verify.

@laidypus said in Rocky Linux 8 (RHEL Potential for Performance Issue:

@ustinB We currently pay for support on this product, and it supposedly supports Rocky Linux 9,

Then call the software vendor and have them fix their code.... I don't see how this is at all related to XCP-ng or XO, but rather is only this software vendors issue.

Or are you saying that it this software is supported on RHEL, and you're using Rocky linux to avoid purchasing a RHEL license?

@laidypus support, is like a recommendation. It means that the vendor of this software won't help you out if you try to run it on Rocky 9 or later.

The questions I would raise is; Are you actively using support (paying for support) on this software? If so why not just upgrade the software so it supports the current release cycle?

If it's anything other than "we hadn't thought about it" then it's the sunk cost fallacy at which point, stop caring about the "support" and just install it on Rocky 9.

@iotrlotr1 said in XO New Pool Master:

@ustinB No, no... look at the "Label" column.

The question is - why after detaching hosts from pool, they all have "Label" the same as pool master?

All of these hosts are in different pools, the individual host name is moot once joined to a pool (at least it appears to be).

Are you unable to rename the hosts to something else?

@ndrew no, you would only connect the management IP address of a given host to XO, either as a standalone pool or as a part of an existing pool.

Is the goal to have a redundancy should you lose a network interface that is the "management interface"?

@iotrlotr1 A host can only be a part of a single pool at one time, so when you add your new master to XO, the other hosts in the same pool will disappear from the XO hosts page.

That is expected behavior

@uckertt said in Multiple AD sources to Xen Orchestra:

@ustinB so its as much a compliance piece as anything else. UK instance of a US company with data sovereignty laws in play. The administrator AD is UK only and the other AD can be anyone

GDRP is really a bit of a pain in the butt, because a username is covered under GDRP and that the username has to stay within the user's country.

The question I would raise is there a better way to limit this data into its required geographic region, like multiple XO instances and pools. Rather than one large pool, which would then be configured to allow people to access the resources from different geographic regions while keeping things GDPR compliant.....

The Vates team, being from France likely has some ideas on this that would be worth* consulting with them on.

@uckertt said in Multiple AD sources to Xen Orchestra:

@ustinB so its as much a compliance piece as anything else. UK instance of a US company with data sovereignty laws in play. The administrator AD is UK only and the other AD can be anyone

You're allowed to have shared hypervisors? Do these servers operate in the Atlantic ocean?

@cHenry said in Large incremental backups:

@ustinB

Other hypervisors I have used do not perform the healthcheck as an auto restore on a different host so I cannot say. It would be good if the healthcheck could start the VM with the minimum memory value configured.

Those minimums aren't really "minimums" in the sense that you're thinking. They are the template minimums and changing those configurations on the fly would actually impact the guest as a whole from its startup.

Changing the dynamic memory to use something less than the guest's configured Memory causes other issues with backups, I'm not certain as to why, but I've found other administrators who have changed that setting to 32Gb/64Gb and then suddenly the VM can't be backed up or has other issues. Someone else would have to elaborate as to why this is the case though.

Setting the same to 64Gb/64Gb fixes said issues.

You shouldn't be looking to do this, you're customizing your environment in such a way that the community would likely struggle to assist, although maybe the Vates team would be willing too.

Lawrence's comments notwithstanding, how would XO know which AD is authoritative, permissions administration is going to be a nightmare.

While there are multiple plugins for Authentication to XO, I would doubt if you could use multiple plugins at the same time as I've never bothered to try to use multiple, though this may be the most reasonable approach to try to achieve what you're asking for.

IE maybe one company uses GCP, so you authenticate that org with the auth-google plugin, and the other you authenticate with the auth-ldap plugin.