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

@henri9813 said in Multiple disks groups:

hello @DustinB.

Yes you right, i would perform this to be able to have VDI with more than 1TB disk. ( which will not be possible because my smallest disk is 1TB (so, 879GB )...

Is that actually a limiting factor? It makes sense, but I've never used XOSTOR so I'm not completely sure what the limitations are.

My assumption would be you'd have the same 2TB limit, but again, I honestly don't know.

@rzr but why.... what example use case would this be useful in?

@arovella74 said in Definition backup full & incremental.:

1. Our S3 bucket fills up with objects.

Set up retention and deletion rules on your bucket so your bucket is cleaning this out.

@arovella74 said in Definition backup full & incremental.:

2. We want a full backup to be performed every two incremental runs, so we can keep the S3 bucket in check.

Without more details I'm not sure how you could do that, besides alternating schedules, specifically run an incremental bi-weekly (for simplicity) and then run a full every 3 Saturday.

@arovella74 said in Definition backup full & incremental.:

@olivierlambert The idea is that by putting two S3 repositories together you distribute the copies and don't duplicate them.

You'd have to do this with different backups, or maybe with a Job..

@henri9813 XOSTOR is "vSAN".

You ideally would want to consume all of your disks across all of your hosts to create an as large and as performant VG as possible. Splitting your disks into different VG's not only would decrease your performance, but is also likely hugely complex and outside of the original design scope for XOSTOR.

@noritaka971 said in cleanVm: incorrect backup size in metadata:

Hi,

Last back up have always this message (XOA 5.109).
And incrémental backup have a Full Size... (ticket open on support)

I've had this issue for months with XOA and I've been told to not worry about it. Surely there is some way to recalculate the size of the VM backup to address this warning.

@acebmxer Right, before you migrate from ESXi to XCP-ng, you must remove the VMWare tools.

Before doing that though, take a snapshot (or proper backup) ahead of any changes this way you have a way to rotate back if something isn't working.

@acebmxer Yeah why wouldn't you take a snapshot before altering your production workloads?

As a heads up, XO Backups are not application aware, so backing up a DC or Database Server can cause you to lose data if the database is in the middle of a write operation.

But yeah, absolutely make a backup before you migrate a workload so you have a perfect system state to restore too should something go sideways. Of course the VMware/XCP-ng Drives aren't critical to the VM operating, they do offer better performance.

@KPS Are you geographically separated from your XCP-ng hosts? I've noticed from time to time due to internet latency that I don't always see the grub menu.

For example this pool has 4 hosts.

But from the connections screen I only have the pool master connected to XO.

This scaling back of the connections under the "Server" settings is done after the secondary hosts are added into my pool.