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!

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?

@stormi OK this is a good point. My thing is that I generally don't like to modify things from near default in a prod environment because some update comes along later and breaks it.

To be fair though, I've never had this happen with XCP-ng in my lab and I also doubt something related to certs and secure boot would cause that, so maybe I'm paranoid and incorrect here.

Also, my apologies, I missed the reply about working on a fix.

This all makes sense to me now though, and the fix is pretty easy to get the automated install to work.

Thanks for all the help!

@Darkbeldin Thanks! I followed this response here, which is changing the same line: https://xcp-ng.org/forum/topic/5200/secureboot-certs-install-fails/6

Works fine now!

@andyhhp Will do, I'll link it here once I post it, probably can get that done today once I'm done with work lol.

Thanks for the willingness to help btw!

Today's blog post mentioned Mirror Backups, a new way to backup an entire Backup Repository instead of the VMs themsevles: https://xen-orchestra.com/blog/xen-orchestra-5-83/?utm_campaign=mail_5.83&utm_term=logo

I decided to go ahead and update a XOA instance to Latest instead of Stable to test this, and so far it's been amazing.

For some reference, my XOA only has 8GB of RAM and is maxing it out with these backups, so the speeds I mention may not be the fastest it can go. This server has a 10GbE link to an SMB share for backups and then a 2GbE link WAN to backup to Backblaze.

I am seeing speeds in the 200Mbps range (megabits, not BYTES) per second, which is over double what I was seeing with doing individual VM backups to Backblaze B2, this is super awesome and doing it with full backups means there are no delays due to merge times either.

Just wanted to start a post to say how awesome this feature is, I love the idea of it and thank you Vates team for making this happen, it's a very unique way to do things and is excellent!

If I'm being honest here I don't really find the messages as annoying as you are making them out to be. Sure if I had a choice I would want them gone, but it's really not a big deal, 1-2 clicks and they are gone until the next time I login. I also kinda like the reminder on the sidebar about no support, helps me remember that A. I'm in my lab environment and B. I'm using a from the sources version so I need to manually do updates etc.....

Normally speaking you wouldn't have multiple subnets/IPs on a single virtual NIC, the best route to go is to add another NIC and assign IPs on that end.

What is your goal here?

@JamesG You are correct about that, this is another reason I use the Citrix ones personally.

Also, as I mentioned above, don't forget that you can't use secure boot with the XCP-ng tools.

@olivierlambert Yeah no worries, was a minor issue overall anyway!

Just figured I'd make my own post about it since the other post mentions CR but not Disaster Recovery, the fix definitely works for both though!

Update, going to 5.83.2 fixed the issue, so it was related to the same issue referenced about CR not removing old VMs, also looks like it's cleaning the old VM directory which is great news too, I'll double check things when it runs.

Great work on the super fast updates from the Vates team!

Not sure if this is actually related to 5.83.0 or possible the CR issue, but I'm having delta backups fail with the below error, it seems the backups themselves are getting created just fine though:

Cannot read properties of undefined (reading 'vm')

Anyone else seeing this? Not quite sure what this actually means, backups worked fine yesterday though and I updated to 5.83.0 a few days ago.

@olivierlambert Sounds good, I'll do more testing too. If there is anything you all in specific want me to test let me know!

@planedrop As a quick update to this, I can also verify the Rx traffic is all coming from the SMB share of the NAS, so it's not something else causing higher Rx traffic than Tx.

@olivierlambert Makes total sense, this is super awesome.

I did want to ask, after running for about an hour speeds dropped off (only a little though) but I'm seeing a huge spike in CPU usage on XOA along with higher RX than TX (whereas before RX and TX were about the same and CPU wasn't working very hard), is this normal? Just curious since it's a new feature trying to provide as much feedback as I can.

I'll still test this all again with some more test VMs once I boost XOA up to a more powerful VM.

@olivierlambert No problem, what an awesome feature! I'll do more testing too with a beefier XOA install with more CPU and RAM and see if performance goes even higher, but 200 Mbps is enough for even pretty large VM setups to backup overnight!

Today's blog post mentioned Mirror Backups, a new way to backup an entire Backup Repository instead of the VMs themsevles: https://xen-orchestra.com/blog/xen-orchestra-5-83/?utm_campaign=mail_5.83&utm_term=logo

I decided to go ahead and update a XOA instance to Latest instead of Stable to test this, and so far it's been amazing.

For some reference, my XOA only has 8GB of RAM and is maxing it out with these backups, so the speeds I mention may not be the fastest it can go. This server has a 10GbE link to an SMB share for backups and then a 2GbE link WAN to backup to Backblaze.

I am seeing speeds in the 200Mbps range (megabits, not BYTES) per second, which is over double what I was seeing with doing individual VM backups to Backblaze B2, this is super awesome and doing it with full backups means there are no delays due to merge times either.

Just wanted to start a post to say how awesome this feature is, I love the idea of it and thank you Vates team for making this happen, it's a very unique way to do things and is excellent!

@florent Did some testing with this and wanted to let you know how long it's taking, I haven't tested the test branch yet but I am using NBD.

I had a VM with a 25 gibibyte delta that needed to be merged to Backblaze B2, this is on a 200Mbps upload connection, the upload of the new snapshot only took a few seconds (it was like 100 kibibytes), but the merge of the previous 25 gibibyte one took 2.5 hours to complete, does this seem normal?

I haven't been able to find more info on this, so figured I'd make a post.

From the post about NBD back late last year, there is a note that mentions to only enable NBD on the network used by Xen Orchestra, I just wanted to make sure I 100% understand this.

If I say have a physical interface with a pool wide network on eth0, then on "top" of that I have a VLAN for management purposes and that is what I use for Xen Orchestra access (and the only network attached to it), should NBD only be enabled on the Management VLAN or should it be enabled on the "pool-wide network associated with eth0"?

Just wanna be sure I am doing this right so I don't break anything.