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.

@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?"

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

@abudef The English translation is meant to be "Prevent Migration".

I think some lines were crossed ha.

@coolsport00 said in XO Pool Management:

@DustinB Thanks Dustin. If my Slave loses network again...I'll run that cmd. Hopefully not though!

Question if I may - does it matter where I configure my Host networking? Meaning (not my Mgmt ntwk..that's upon install), but if I want to change Network names/desc's, do I do that after adding Hosts to a Pool, or just go ahead and do it on the Hosts before adding them to a Pool? When I had my issue mentioned earlier above..I literally hadn't done anything but added 1 Host to my other in a Pool and just began homogenizing Networks, as well as adding a couple other VLAN networks. That was it..then bam!...issues on my Slave.
Thanks.

I've always configured and setup my hosts into a pool, then went in and made any descriptive changes once the environment is setup.

Making changes on a per host basis doesn't really work or make any sense as they would be superseded by changes made at the pool.

@coolsport00 From your master over SSH (or console)

xe host-list
xe forget-host uuid=<Slave-UUID>

The question that is begging to be answered then is would Change Block Tracking (CBT) address this issue?

Presumably it would, but as the post is still actively getting updates, https://xcp-ng.org/forum/topic/9268/cbt-the-thread-to-centralize-your-feedback

@sotero I'm not aware of any particular issue off hand. It seems like the hardware is operating as expected...

Were all of these units shipped from the manufacturer "ready to go" aside from having XCP-ng installed?

@sotero This may seem odd, but are the CPU fans actually working? I know there are hundreds of people who are using Intel CPUs (likely the same exact model) that aren't experiencing the same issue.

My initial thought is that these servers you have, has some kind of hardware or firmware issue where the CPU Fan simply isn't working.

@Statitica have you checked the Event Logs, specifically the System event logs? I recall having a performance hit when I migrated some VMs from Hyper-V to XCP-ng (years ago at this point).

I don't recall the exact issue off hand, but the remedy was easy enough.

@icompit gotcha, while I generally understand the reasoning behind this, it doesn't work like this practically.

If you're moving your VM's around from one host to another in an unmanaged environment, that would mean that the VM could run in multiple locations at once which would negatively impact your licensing costs.

Whereas if you have 1 pool, the VM can only be running on the singular pool once without you making any changes to that system.

Of course if you removed the NIC or sysprep'd a VM then it could run somewhere else, but those are fundamental changes to a given VM.

Why not have you're hosts in a single pool, then when you're performing maintenance the system manages moving your VMs around for you?

Just curious, while I do agree you should be able to cross pool migrate VMs without issue, I'm trying to understand the use case you're using here.

@the_jest Ah my misunderstanding, well that sounds like it should be fine for day to day operations then for the cabinetry. You might have to look at the components within this unit (the CPU and cooler itself).

I'm assuming this was a system that was "bought off a shelf" and not assembled by you. CPU heat issues can be annoying to deal with, but pretty simple.

Open the case, remove the heatsink, clean it up with some Isopropyl Alch (80% or higher) add some new heatsink gel and go from there.