@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.
Posts
-
RE: XenServer VM Tools 9.3.3 from Citrix causes bluescreen
-
RE: Some guidelines for sizing a XO server ?
@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
-
Some guidelines for sizing a XO server ?
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 -
RE: Shared SR (two pools)
@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.