Offline
@sid It seems I have to get my hands dirty and take a deeper look into Terraform / OpenTofu. I am not shure how well the other folks at work partially will have fun working with commandline versus the easy to use XO web GUI. 
Tailoring down the CloudInit files used is not really the basic idea behind this. I was rather going the oposite way and install / configure the stuff we usually bake into our templates on the fly while generating the VM via CloudInit.
Thanks a lot for all the responses ! 
Thanks for your replies ! Yes, using both an external editor plus some sort of revision control (Git, SVN, etc) makes perfectly sense but somewhat destroys the user experience of XO having everything to administrate, create and backup all the VMs in your infrastructure in the first place. 
I for example had issues with hashed password for new users being generated via CloudInit and it took me quite some time to find out what causes my user generation to fail. Everyone dealing with CloudInit a lot more than I do will agree that those init files often are technically correct but still fail for some strange reason where you need to find out a workaround. So adding another limitation like those strangely small edit boxes for something that would easily need a screenwide text box does not really make sense to me. If you edit preconfigure init files it would be nice to simply have a "save" button for example.
I am not really a web dev but I guess there would be available text editor components for fill this gap without needing 20 man days to implement such a feature. All this Terraform / Open Tofu stuff is nice but I guess generating VMs via Cloud Init and XO will be the entry level for everyone before trying out a much bigger infrastructure as code solution, right ?
Sorry if this has been asked before but just recently I started to play around a bit with CloudInit to make provisioning of Linux VMs in our XCP-ng intrastructure a bit easier.
Dealing with Cloud Init files itself is already not really easy but XO makes this even harder because of the tiny edit window inside the web gui. I know that for more complex tasks using Cloud Init together with Terraform / Open Tofu plus the XO provider is the better way to go but for the beginning it would help to have a true editor inside the WebGUI (may be with YAML syntax validation) plus an easier way to manage various Cloud Init files (e.g. Network #1 fixed IP / Network #2 fixed IP / Network #1 DHCP / etc). Some sort of file / config manager that allows to easily import and export cloud configs to /from external storage.
@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:
Thanks in advance !
@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:
TIA,
Holger