@igor You are welcome !

@igor Yes, if you reboot the VM multiple times you will get into the troubleshooting / repair menu. Choose extended startup options and use safe mode / protected mode for normal bootup. After successful startup of Win2k22 simply log into your VM, reboot it in normal mode and everything should be working fine. Use the device manager to remove any storage adapter / NIC which is grayed out. Reboot once again and your W2k22 VM should be fine. For the 32 Win2k22 VM I recently did in XCP-ng about 40% failed booting with BSOD.

@Nick-085 Thanks for the hint mate ! I wasn't aware that this script also installs a XO proxy. In the mean time we already have something like backup proxies in place because we splitted backup jobs to two XO instances in the first place since we wanted to separate test environments from "production" (so to speak). A third instance is used mainly for centralized administration (we are only slowly moving away from using "Xencenter" since we are long time Citrix Xenserver users). I guess old habbits die slowly. In the end I guess by coincidence we already build something similar to what a central XO instance plus two XO proxies

@Nick-085 Thanks for answering. We have been using XO on a rather "beefy" VM with 6 cores and 16 GB RAM. Lately we added a lot of backup jobs to the host and run into some issues of backups failing because XO reported that the backup remote is partially not availabe. After increasing RAM the issue seemed to have moved away. I guess I will have a close eye on this but not invest too much time if more RAM solves the problem.

Hey there,

we are using XO build from sources in a Ubuntu VM. Mainly to have scheduled backups of important VMs but we are slowly adopting to use XO instead of XCP-ng Center (which is depricated anyway) for administration purposes.

Are there any guidelines / rule of thumb for the sizing of the VM in regard of CPU cores / RAM ?
I mean like 8 cores and 16 GB for managing 400 VM+ ?

TIA,
Holger

@jimmymiller Without more details on the VM (use case, OS, etc) it is hard to answer but I would rather try to remove the big amount of data from the virtualisation host themself. Tom Lawrence once suggested that for larger amount of data you should not store them within a Xen VHDD but rather on a ZFS storage as dataset (for files) or zvol via iSCSI (for block storage). Then attach the external data store (so to speak) via smb, nfs, iscsi from within the VM. Classical storage systems like FreeNAS, TrueNAS and the alike are much better in handling fast access to big amounts data. This way the base VMs moves quickly between hosts. Even with larger amounts of data. From my experiences VMs with big virtual drives always hurt you for backup / migration / etc.

The Xen / XCP-ng equivalent for VMXNET are Xen PV device drivers which either come from Citrix Xenserver, XCP-ng or the Xenserver project itself. Check the Wiki. It describes the installation pretty well:
https://xcp-ng.org/docs/guests.html#windows

As for 3D acceleration within the VM there is hardly a comparable option unless you do some PCIe pass through of a GPU.

@Mt_KEGan You could try Windows System repair or reboot the system in safe boot mode. It solved the BOD for our systems yesterday. Win2k19 should behave similar to Win2k22 and show up repair mode & advanced boot options after one or two boot failures.
HTH.....

We have had similar issues with an older version of the Citrix Xenserver tools (9.3.1) and several Windows 2022 servers. Windows 2k19 worked fine so after after a double reboot.

@florent Thanks. OK, so for one time remote migration I will be fine with multiple rsync runs plus switching the central remote for my backups. Nice to have both options though.

@olivierlambert Thanks at lot for the quick reply.
In regard to my question number 2 I never took notice for the mirror backup function. That helps !

Hey there,

I have two questions in regard to remotes:

1. How does XO handle backup jobs to multiple remotes ? In example if I have attached and configured two nodes for a backup job. Are the files stores parallel to both remote locations ? Or are they stored sequentially to remote "A" and then to remote "B" ?
2. What it the best practice (so to speak) for migrating existing backups to a new location ?
   Simply sync them over to the new remote, configure the new remote to each backup job and remove the old remote ?

Thanks in advance !

• Holger

@olivierlambert Thanks for your quick reply.
Fair enough...I didn´t try XO as appliance in the first place.

There is this one XO install script from this guy called Dustin B: (https://github.com/Jarli01)
https://github.com/Jarli01/xenorchestra_updater

Has worked flawlessly so far and from what I tell so far XO is pretty similar to what you get when following the XO from the sources guide.
As for the storage protocol used: Would you suggest NFS over SMB ?
We do no fancy incremental backups. Only full backups without RAM from snapshots.

Thanks,

Hey there,
we are using XO to backup VMs from both XCP-ng and Citrix Xen-Server. We use a DIY FreeNAS instance on a beefy server with external SAS HDD enclosure via SMB as remote. Our Xen Orchestra is build from source via install script on a Ubuntu 22.04 server. In the recent time we have seen backup jobs fail with what seems to be some sort of Samba timeout issue. Typically the kernel log of the XO host show something like this:

[1508788.516400] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[1509688.124079] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[1509688.124115] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[1510588.329807] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[1510588.329848] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[1516245.125756] CIFS VFS: \\172.25.20.29 sends on sock 000000009e27dde1 stuck for 15 seconds
[1516245.125805] CIFS VFS: \\172.25.20.29 Error -11 sending data on socket to server
[1526634.554814] CIFS VFS: \\172.25.20.29 sends on sock 00000000ada8aee7 stuck for 15 seconds
[1526634.554870] CIFS VFS: \\172.25.20.29 Error -11 sending data on socket to server
[1526698.938970] CIFS VFS: \\172.25.20.29 Send error in SessSetup = -11
[1529188.866336] CIFS VFS: \\172.25.20.29 has not responded in 180 seconds. Reconnecting...
[1548386.401279] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[1548386.401306] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[1569985.548675] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[1569985.548702] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[2027171.988655] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[2027171.988682] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[2028071.838874] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[2028071.838898] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[2028971.872043] CIFS: Attempting to mount //172.25.20.29\xenexports/xohn
[2028971.872077] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[2041130.424668] CIFS VFS: \\172.25.20.29 sends on sock 000000002ff9cdef stuck for 15 seconds
[2041130.424727] CIFS VFS: \\172.25.20.29 Error -11 sending data on socket to server

The strange thing here though: The FreeNAS used for storage is connected via 2x10 GBit SFP bond to our main switch. All Xen servers which are accessed via XO also run a 10 GBit NIC as Management interface.

I tried (as experiment) to set a timeout for the SMB remote in XO via -o option.
This is specified in te samba docs:
-t|--timeout <timeout-seconds>
This allows the user to tune the default timeout used for each SMB request. The default setting is 20 seconds. Increase it if requests to the server sometimes time out. This can happen when SMB3 encryption is selected and smbclient is overwhelming the server with requests. This can also be set using the timeout command inside smbclient.

But unfortunately XO simply replies with an error message "CIFS: Unknown mount option "--timeout 60""
I guess this is because we are talking about CIFS and not a plain mount command with Samba options ?

My main questions here:

• Has anyone doing full VM backups from snapshots to a SMB share experienced similar error messages ?
• Is there an approach to modify the default SMB timeout which seems to be 15 seconds ?

TIA,
Holger