I had two servers in SBG. Thankfully nothing that wasn't already replicated elsewhere.
Servers were offline. Logged into XO backups all there :). Commence restoring.
So thanks to Xen Orchestra for making what could have been a disaster into no big deal.
Does this basically mean there could be effectively a new version of XOSAN which can leverage local storage across a cluster?
I realise it may come across as annoying. But 8.2 being out before xcp-ng Center support catching up has highlighted an issue for me.
I use XO for a lot of things. Especially the backups process. But it being the only option for admin of 8.2 has to be frank, frustrated me.
It is just my way of working. But I do everything from the xcp-ng Center tree view. Collapsed it shows my entire infrastructure then I can expand the list to show VMs on machines I'm interested in, and importantly do this on several machines at once, sometimes all of them, and see exactly what is going on.
This is harder in XO. All the information and functionality is there but much more hidden away on different screens and more difficult to get a quick view of what is going on.
I hope you take this as friendly feedback 
I have an SQL Server instance which has a 1TB main drive disk and then a shed load (technical term 
) of other disks for storing the databases. The whole thing takes up too much disk space for snapshotting to work.
Is there any means to use XO to back up just the boot disk and not back up the data drives? These are backed up by other means anyway.
Servers to be backed up, all in OVH.
20x xcp-ng8.0 1-2Gbit NIC
SATA hard drives. Not the fastest in the world but can usually manage 20-30MBbps during live migration or VM transfers.
Backup server
xcp-ng8.0 10Gbit NIC.
SAS hard drives 12x arranged in RAID0. xcp-ng and the VMs run from a single SSD drive.
VMs on the server:
XOA
Centos7 server with the RAID array direct mounted, XOA accesses this through NFS.
XOA and the Centos7 server communicate using a network internal to the xcp-ng server.
Testing on the RAID array from the NFS server using dd gives speeds of around 600-800MB/s reading & writing.
I've tested backups by setting a seperate backup job on 10 of the xcp-ng servers, none of them are in a pool, all seperate installs. For the first few machines they amount of data received by XOA and passed onto the NFS server goes up, then it's maxed out at around 70MB/s. Any further machines sending backups through to XOA doesn't increase that total instead reduces the individual speed of each of the backups.
The network input to XOA is a constant 70MBps (give or take) but the output to the NFS server is in pulses maxing out at around 200MBps.
I've done some network testing and using simultaneous iperf from 5 servers I've managed to max out the 10Gbit NIC so the network connectivity into there isn't in question. I wasn't able to test the connectivity into XOA itself, so that could still be a bottleneck, it does seem busy CPU wise.
Any advice as to where to look and what to try? The backup performance isn't bad per-se, it just could be better given the hardware.
There's always the possibility I've made a hideous multiplication by 10 error here somewhere.
As the title. I am getting this error when backing up a particular VM. All the other VM backups are running ok.
Any ideas on how to resolve it?
1 Failure
UUID: 3de6c09a-7bd5-3552-eb25-9e641296ca9f
Start time: Wednesday, October 20th 2021, 5:00:00 am
End time: Thursday, October 21st 2021, 12:05:59 pm
Duration: a day
Error: footer1 !== footer2
@olivierlambert said in XO console keyboard on iOS and iPadOS - no input possible:
No but it doesn't mean this won't be solved with a virtual keyboard anyway
It would need to be able to trigger the built in iPad / iPhone keyboard for it to be properly usable.
Having just got an iPad I’ve noticed this too. Have to RDP to my office machine to get onto xcp-ng Center. Ideally it would be great to have an iPad app as interface to XO. But of course won’t happen.
@olivierlambert said in OVH fire:
Hey @markhewitt1978
You are exactly the kind of user we'd like to put some spotlight on. Would you agree to do a small written interview with us for a blog post?
Sure no problem. I don't think there's any confidentially issues. But I'll have to run any answers past management.
I had two servers in SBG. Thankfully nothing that wasn't already replicated elsewhere.
Servers were offline. Logged into XO backups all there :). Commence restoring.
So thanks to Xen Orchestra for making what could have been a disaster into no big deal.
I realise it may come across as annoying. But 8.2 being out before xcp-ng Center support catching up has highlighted an issue for me.
I use XO for a lot of things. Especially the backups process. But it being the only option for admin of 8.2 has to be frank, frustrated me.
It is just my way of working. But I do everything from the xcp-ng Center tree view. Collapsed it shows my entire infrastructure then I can expand the list to show VMs on machines I'm interested in, and importantly do this on several machines at once, sometimes all of them, and see exactly what is going on.
This is harder in XO. All the information and functionality is there but much more hidden away on different screens and more difficult to get a quick view of what is going on.
I hope you take this as friendly feedback
@olivierlambert said in Backups not restoring xcp-ng8.1:
The UUID is really unique. So I suppose the check is on something else. If you can explore logs to get what's blocking it might help us to narrow it
Checking between restore and original. The VM UUID is different. The VDI UUID is different. Not sure what else there is.
@olivierlambert said in Backups not restoring xcp-ng8.1:
You reported your problem, you are asking for something, I'm all ears for suggestions
We should think about the best approach. Actions:
- Try to find where those changes were made (in XAPI?)
- Analyze reason of these changes and maybe discuss that with XAPI devs
- Choose a solution according to our investigation
Thanks! It would be good to get a workaround too. It doesn’t go from MAC address as I’ve tried changing the address and tried deleting the network interface which doesn’t work.
So perhaps it’s looking at the UUID of the VM? Is there a way to change that, or other way such that it now thinks that VM is not a duplicate.
Or perhaps that’s something that could be added to the backup restore system such that it restores with different details such that it doesn’t trigger the duplicate error?
@olivierlambert said in Backups not restoring xcp-ng8.1:
It might be a new check introduced in XCP-ng 8.1 then.
What approach do you suggest?
Isn’t that for you to decide? :).
Obviously I would prefer that check wasn’t there.
@olivierlambert said in Backups not restoring xcp-ng8.1:
So you restored the VM without any problem on the "other host", but when you want to migrate that restored VM on the original host, it fails to do so, right?
Correct. It only works when I’ve deleted the VM that it is a backup of.
I’m sure you can see why keeping a copy of the source VM would be a good idea.
Notably the only reason I was restoring the “other” host was because the restore process hung on the main host. Which may or may not be related.
