Hi everyone,

I just installed this 8.2.1 a Dell R630 and the installer was very smooth.
We chose to make a new installation since the host was running XS 7.2 and we wanted a fresh install, with that came the opportunity to leverage EXT and thin provisioning which seems to work just as it should.

We're also mounting a NFS SR for VM disks which works fine as well. I'll have to wait and see, but hopefully the problem with /var/log/snmpd.log is resolved now and no more alerts regarding disk usage

We're using Veeam for our VMware platform and XOA for our XCP platform and I have to say I prefer XOA. Why may one ask?
Well it is dead simple, its not bloated, you have a ton of options when it comes to configuration, destination, scheduling and so on.

Veeam on the other hand is A LOT faster, we're using a 10G link to our backup site and we're seeing speeds over 7Gbit/s when backing up our VMware platform and I know this is something Vates is working hard on improving in XOA.
Veeam also has application aware backups which is a big deal when you're running MSSQL inside your VM's - I dont think there is any plans from Vates in supporting this and this might be a big deal for customers comming from the VMware and Veeam-side.

According to Microsoft you need to use their built in backup feature or a software that supports AD and VSS which will tell the VM OS that it is going to be backed up.
Unless you do this there might be corruption of the AD Databases according to Microsoft.

ALL THO we've been backing up our AD servers with XOA snapshots (Both normal backup and incremental) and had only 1 issue since we started using XOA in 2016.
Since that issue we also use a guest agent (From Ahsay CBS) that makes a Windows System State backup and Windows System Backup.

More info about that can be found here:

https://wiki.ahsay.com/doku.php?id=public:version_9:client:9447_system_state_backup_vs_system_backup

A great opportunity for anyone who is into xcp, xoa and opensource software to join a great company

olivierlambert said in XCP-ng 8.2.1 (maintenance update) - ready for testing:

Thanks a lot nikade for your feedback! (also I love your avatar!)

Yeah, I gotta have my suit on my tux

I wanted to inform that I've tried iSCSI with multipathing as well and it works fine.
So far everything we need in our general production-environment seems to be working as it should.

Greg_E said in What should i expect from VM migration performance from Xen-ng ?:

nikade

I've spent a bunch of time trying to find some dark magic to making the VDI migration faster, so far nothing. My VM (memory) migration is fast enough that I'm not concerned right now. and don't have any testing to show for it.

Currently migrating the test VDI from storage1 to storage2 (again) and getting an average of 400/400mbps (lower case m and b). If I do three VDI at once, I can get over a gigbit and sometimes close to 2 gigabit.

It's either SMAPIv1 or it is a file "block" size issue, bigger blocks can get me benchmarks up to 600MBps to almost 700MBps (capital M and B) on my slow storage over a 10gbps network. Testing this with XCP-NG 8.3 release to see if anything changed from the Beta, so far all is the same. Also all testing done with thin provisioned file shares (SMB and NFS). If I could get half my maximum tests for the VDI migration, I'd be happy. In fact I'm extremely pleased that my storage can go as fast as it is showing, it's all old stuff on SATA.

I have a whole thread on this testing if you want to read more.

You can see the migrate which was 400/400 and then the benchmark across the ethernet interface of my Truenas, this example was migrate from SMB to NFS, and benchmark on the NFS. Settings for that NFS are in the thread mentioned and certainly my fastest non-real world performance to date.

That's impressive!
We're not seeing as high speeds are you are, we have 3 different storages, mostly doing NFS tho. We're still running 8.2.0 but I dont really think it matters as the issue is most likely tied to the SMAPIv1.

We also noted that it goes a bit faster when doing 3-4 VDI's in parallell, but the individual speed per migration is about the same.

planedrop said in XO - Restore Health Check:

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.

Thanks for verifying, it is probably an easy fix for the vates ppl

Hi everyone,

Has anyone else tried the Restore Health Check-feature in XO to test their backups?
I've used it now in my lab a couple of times and it works great, but one thing that bugs me out is that the name of the tested VM is no longer dispalyed after the TEST is finished because it was removed:

Instead of listing the name of the VM it just says "VM not found!"

We're using XO from sources:

Xen Orchestra, commit 8b7e1
Master, commit 587da

Dataslak said in After installing updates: 0 bytes free, Control domain memory = 0B:

nikade olivierlambert stormi Danp yann

Just wanted to say to you all:

Thank you for your contributions and kind helpful assistance which has helped me through this crisis.

I would have been in deep trouble without you. I respect your expertise, and appreciate deeply that you are working so hard to help us dumb users. I have learned a lot, and hope one day to become skilled enough to at least help other new users on this forum.

Best wishes
Aslak

Happy everything worked out, this is what this community is all about.
I've gotten a lot of help and given some too, it's all about helping out with the things that you can.
With time you'll be able to help out more and more and more

planedrop said in Veeam and XCP-ng:

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.

Well said, I totally agree.

tjkreidl said in Issue with SR and coalesce:

nikade Am wondering still if one of the hosts isn't connected to that SR properly. Re-creating teh SR from scratch would do the trick, but a lot of work shuffling all the VMs to different SR storage. Might be worth it, of course, if it fixes the issue.

Yeah maybe, but I think there would be some kind of indication in XO if the SR wasn't properly mounted on one of the hosts.
Lets see what happends, its weird indeed that its not shown.

Byte_Smarter said in Issue with SR and coalesce:

tjkreidl

Maybe I am reading this wrong but the SR is not there in a mount? but also it is viewable and working in XO and lists usage and all that?

It should definitely be listed here, I'd start over and see if it shows afterwards.
Remember to fully destroy and remove the SR (which will obviously remove all data) and then re-create it to make sure there's no weird stuff left.

Something feels wrong, it writes to the log that there are 23 VDI's to be deleted on SR with uuid 6eb76845-35be-e755-4d7a-5419049aca87 but you say there's not snapshots.
It doesn't add up or am I missing something? How many VDI's do you have on the SR?

That's weird indeed, I wonder what those 23 VDI's are then.
What is the uuid of this new SR? 6eb76845-35be-e755-4d7a-5419049aca87?

I think you can show them from the cli with the following command:
xe sr-list params=name,uuid

Byte_Smarter said in Issue with SR and coalesce:

Mar 15 04:06:41 ops-xen2 SMGC: [19269] Found 23 VDIs for deletion:

This is what makes me unsure, are you sure there is no snapshots on any VM's?

Byte_Smarter said in Issue with SR and coalesce:

tjkreidl I am not sure if you saw my earlier post, I have several TB of space

Are you sure multipathing is disabled on all hosts in the pool?
Also, could you share a larger portion of the /var/log/SMlog ?

As replied by dthenot you need to check /var/log/SMlog on all of your hosts to see which one it is failing on and why.
If the storage filled up before this started to happend my guess is that there is something corrupted, if that's the case you might have to clean up manually.

I've had this situation once and got help from XOA support, they had to manually clean up some old snapshots and after doing so we triggered a new coalescale (rescan the storage) which were able to clean up the queue.
Untill that's finished I wouldn't run any backups, since that might cause more problems but also slow down the coalescale process.

We've also experience trouble almost every time we've updated our pools, ever since the old XenServer days and Citrix kind of recommended "manual intervention" because there was no mechanism to check which hosts that were suitable before a VM is migrated.

I think there has been a lot of work done to XOA tho to handle this, but I might've been mistaken, we just ended up re-installing our hosts and setting up a new pool which we then live migrate our VM's over too and scrap the old ones.

VMWare has some kind of logic, which will try to balance the load between the hosts and if you have DRS it will even make sure to balance your hosts automatically during runtime.
Im pretty sure XOA has this logic as well, but XCP-NG center definately doesn't, so avoid it as much as possible.

I don't think that's going to be an issue with Vates, they have ppl in different parts of the world and they're very helpfull.
Reach out to them and link this forum thread, im sure they will be able to get you going even tho you're in Australia.

Never found any resolution to this, some times you're able to "restore" the keyboard by trying to type some different special characters (in my case | or > or <) but it only works some times.

This is super annoying when you're trying to do some basic troubleshooting inside a VM from the console.