Best posts made by planedrop

@jasonnix I've done extensive testing with this myself, first and foremost, Veeam is the one that would have to support it, not vice versa.

Second, it would be best to use XO for the backups, it's much more fluid and is fully integrated, I've been doing this for some time and it's been excellent in multiple production setups.

I also have tested using Veeam via agents within the VMs themselves (this was just for test purposes, I'd still not really recommend it) and it worked exactly as expected.

Using XO for this is still better though, it's generally faster, easier to setup, more reliable, and much faster and easier to recover from backups.

If you are considering this as a comparison to VMware, it's worth noting that it's not really a positive thing that VMware requires you buy a separate product entirely in order to handle backups.

I can confirm this is the case for me too, not a huge deal, but would be kinda nice if it could keep track of the name.

IIRC the templates help define some of the UEFI specs and things like that, generally speaking though using something similar to what you're deploying, even if not the same version (i.e. Ubuntu 20.04 template for a Ubuntu 23.10) should be functional, at least in my experience this has never created an issue.

@olivierlambert issue added, it's my first time doing it on GH so apologies if I missed anything or put it in the wrong category.

https://github.com/vatesfr/xen-orchestra/issues/7893

planedrop created this issue in vatesfr/xen-orchestra

open Add Email Notification For License Issues To Prevent Backup Failure #7893

I can confirm NFS is great on XCP-ng, would definitely encourage you got that direction, TBH FC and iSCSI are a tad outdated. There are still good use cases for them but NFS is the thing I'd always aim for in this setup.

And like @Danp said, if it's thin provisioned, then no it won't be using double the space.

If you want to work with the backup features, but aren't using this in production, then you can compile XO from the sources and deploy it that way, then use the backup features.

If this is for production though, would def recommend getting support (so purchasing XOA) in case something goes wrong.

I may be able to help out here a bit, I've done a lot of testing and production backups to B2.

Naming wise, Olivier is right, B2 is "S3 Compatible" which is why it works but it's not "officially" supported in that way. However since the S3 compatibility "layer" in B2 has been super solid, backing up to it using S3 protocol should be fine.

As for your question about differentials, whatever backup jobs you setup are what will be put in B2. So if you setup full backups and select B2 as the remote for it, then it's full backups, etc....

I would recommend having your B2 backups be a different job than any local backups though (if you're doing local for faster restore), it's nice having control separately.

@CJ I think there is still some misunderstanding.

A key backup is part of an incremental backup, it's the full of an an incremental.

When you setup an incremental backup there still has to be an initial full backup, then the increments start, this is called the Key backup.

So say you have a Incremental backup setup with a periodic full every 5 backups, you'd see something like this from start:

Key > Increment > Increment > Increment > Increment > New Key > Increment

Each key is a "full" backup but they are called Keys because they are part of the incremental chain so they aren't standalone.

@florent OK good to know, thank you! I will do what I can to replicate this issue in my lab and then see if changing to block backups fixes it, just want to try and avoid changing things too much in the prod environment.

Appreciate the help!

@rjt The setting for backup concurrency within the XOA backup settings.

@Octive Oh gotcha, you can rename the disks as you want within XO itself but don't rename the long UUID.vhd files within the file system, you don't want to mess with those. The UUID is used to track the file itself rather than what you name it in XO. You can't rename the disks to something other than a UUID though (at the file system level).

Any chance this could be a network issue? Are you on a flat network or are things segmented and routed between each other?

I'm just goona say it, tell these clients to stop using 2008 R2 lol. I know you said don't ask, so I won't ask, but I will "suggest" it.

Mostly joking, I get it, have had to manage places before which had no option.

As Olivier said though, that's super old and not supported, I'd suggest swapping to e1000 for the NIC and leaving it without PV tools.

Security and power? I wouldn't say that. VMware certainly has more in depth features and complex scenarios that it can accommodate, but that doesn't make it more secure, in fact complexity usually brings worse security and I'd make a strong argument that XCP-ng is the more secure choice.

Power wise, VMware tends to have a lot of overhead and super high spec requirements for more basic things, so I would also give XCP-ng the lead here, it's extremely efficient and so is Xen Orchestra. Even a basic VMware setup with the lowest end of vCenter Server installed is going to use a ton of RAM and be slow, vCenter also takes absolutely forever to boot.

Unless the situation calls for very specific VMware features, or some vendor says they will only run their stuff on VMware, I'd say it's best to avoid it TBH. It's also been far less stable in my use and when there are issues it's often much harder to resolve them, even with VMware's in depth documentation and KB articles.

It may have already been mentioned in here more recently, but I still think some kind of system to select specific VHDs from the ESXi box would be super nice.

Sometimes one may only need to move the data of specific VHDs (excluding say logging or other temporary data style VHDs) and this would greatly speed up migrations.

It would also help in the event someone has VHDs that are larger than 2TiB, since you'd be able to only move the smaller ones and find an alternate solution for the larger than 2TiB VHDs.

Just a thought though; this tool is still amazing and has helped me start migrations!

@brezlord Yes, looks like the disks themselves are thin but whatever was used thick wise is what the disk is inflated to.

i.e. without the thin=true, a 100GB thick disk on ESXi with only 20GB used would end up taking up 100GB on the SR, but if you grow the disk beyond the 100GB it's all thin at that point, so you could change it to a 200GB and it's still using only 100GB of actual space.

BUT with thin=true, the 100GB thick disk on ESXi that only has 20GB used would ONLY use up 20GB of space on the SR in XCP-ng (so it'd only be inflated to 20GB while still showing the OS it's a 100GB disk). Saves a lot of space if you have VMs with massive disks and low usage (like one of the hosts I am migrating which has 13TB assigned thick disks but only about 4TB is used).

@olivierlambert did I get this right?

@nick-lloyd The issues were the network performance issues, but hardly big enough of an issue to not go with AMD, we're just talking like maxing out at 7 gigabit speed wise.

Also may be worth noting to OP, I have 3 Threadripper systems running XCP-ng, 2 are on 8.2 and 1 is on 8.3, and they're all totally fine and have been very good machines.

@Niko1 Glad you're having a good experience with it!

I have more recently done GPU passthrough and it's been fantastic actually so I take back a bit of what I had said before. For some reason in the past I was having major issues with it and I think I may have had defective hardware (very hard to rule out in this situation though).

Like @olivierlambert mentioned here, you should really be managing things with Xen Orchestra instead of XCP-ng Center, it's a more modern and more feature packed product.

As for your CPU allocations, this all is going to come down to workloads, we can't really know unless we know what each VM is going to be doing.

But I also think maybe there is a misunderstanding about how CPU allocation works in XCP-ng, it's not like you have 10 cores and 2 VMs so therefore give each VM 5 cores so they each can use half the cores, VM vCPUs are basically like processes in a modern OS, and the scheduler in XCP-ng is going to handle which CPU cores get those vCPU processes (I'm oversimplifying but IMO this is a good way to think about it).

So the underlying scheduler will try to balance the vCPUs depending on given workload.

Just wanna say thanks for the awesome work here, I'm not in a position to test these at the moment but wanted to say thanks nonetheless!