@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

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.

@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 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.