@john-c This is just the properties window of the driver that was not installed correctly:
Driver provider: Unknown
Driver date: not available
Driver version: not available
Signature: not digitally signed
The window below says:
Driver files for this device are either not required or have been loaded.
On a Windows 2022 Server VM with uefi boot the Installation of 9.3.3 via Windows Update or directly via update file from Citrix causes a blue screen with inaccessible boot device.
Are there others who have had the same experience?
I use XenServer since 2009. In 2008 i compared Hyper-V, VMware and XenServer for about 6 months (only the free versions) and my winner was XenServer. Not only because I am a fan of Open Source I choosed XenServer. My primary focus was performance and usability (for admins). VMware was too slow on low end hardware like HP ML110 and Hyper-V needed an AD. So I stayed with XenServer.
Since XenServer 7.3 I looked for alternatives and found the XCP-ng project.
I have a small IT company with 3 employees. We serve small and medium-sized customers. Unlike other IT companies around here, we use a lot of open source to offer alternatives to our customers. About one week ago I tested Xen Orchestra (compiled from source) and I like it a lot. I miss some features, but maybe I have not discovered them yet.
If you have plans to support other languages in Xen Orchestra, I can assist you with the german version.
@olivierlambert
Hello,
there's actually not much missing for implementation.
start-delay is already present in the VM settings.
Two parameters are missing:
The vApp is created with the following command:
xe appliance-create name-label=name-label [name-description=name-description]
The VMs are added to the vApp with the following command:
xe vm-param-set uuid=VM-UUID appliance=appliance-uuid
Remove from vApp:
xe vm-param-set uuid=VM-UUID appliance=
vApp-Start:
xe appliance-start uuid=appliance-uuid [paused=true|false]
vApp-Stop:
xe appliance-shutdown uuid=appliance-uuid [force=true|false]
If multiple VMs have the same order number, the longest start delay wins before VMs with the next order number are started. The same applies in reverse order for the shutdown-delay when shutting down a vApp.
vApps are the main reason for me to use XCP-ng Center.
For all my systems I always create a vAPP, which I call Start.
The start order for all VMs and the time delay are then stored here.
When you shut down, this list is automatically processed in reverse order.
vApps is one of the features I miss most in XenOrchestra.
If necessary, from XCP-ng 8.3 onwards I have to switch to the command line to work with vApps.
@john-c I thougt most of the people use the Google Picture Translator. It is not perfect but you can drag an drop the picture to translate:
https://translate.google.com/?hl=de&sl=de&tl=en&op=images
@john-c This is just the properties window of the driver that was not installed correctly:
Driver provider: Unknown
Driver date: not available
Driver version: not available
Signature: not digitally signed
The window below says:
Driver files for this device are either not required or have been loaded.
Workaround for a fresh installation of Windows Server 2022:
I tried a fresh Installation of Windows 2022 Server. Windows Update installs the PV Storage Driver (XSC000 XENVIF 0) and requests a reboot.
If you open the device manager you will see:
Details:
Don´t reboot!!! If you reboot you get a BSOD.
You have to manually install 9.3.3 before reboot. Use default settings and select "Install I/O Drivers Now". This will correct the error.
You can check this in the Windows Device Manager.
Now it is possible to reboot.
@KPS Yes, I rebooted twice. With the "Windows Update Tool" switch in the off position everything is ok.
Normally I always have the switch in the on position.
Summary:
Windows Update Tools off:
Installation of 9.3.3 via Citrix Installer -> OK
Windows Update Tools on:
Upgrade from a previous version to 9.3.3 -> blue screen
Removal of the VM Tools and reinstallation via Citrix Installer -> blue screen after the second reboot
It seems like the error is caused by Windows Update.
@KPS In Xen Orchestra (VM/Advanced) I turned the switch "Windows Update tools" to off.
I manually removed all Xenserver VM Tools, disabled "Windows Update Tools" and after reboot I installed 9.3.3 via Citrix Installer.
Tested several reboots and everything works fine.
After enabling "Windows Update Tools" and rebooting the bluescreen comes back with "inaccessible boot device".
Currently I have disabled "windows update tools" and it runs without problems with VM Tools 9.3.3
It seems like the error is caused by Windows Update.
On a Windows 2022 Server VM with uefi boot the Installation of 9.3.3 via Windows Update or directly via update file from Citrix causes a blue screen with inaccessible boot device.
Are there others who have had the same experience?
@olivierlambert
Hello,
there's actually not much missing for implementation.
start-delay is already present in the VM settings.
Two parameters are missing:
The vApp is created with the following command:
xe appliance-create name-label=name-label [name-description=name-description]
The VMs are added to the vApp with the following command:
xe vm-param-set uuid=VM-UUID appliance=appliance-uuid
Remove from vApp:
xe vm-param-set uuid=VM-UUID appliance=
vApp-Start:
xe appliance-start uuid=appliance-uuid [paused=true|false]
vApp-Stop:
xe appliance-shutdown uuid=appliance-uuid [force=true|false]
If multiple VMs have the same order number, the longest start delay wins before VMs with the next order number are started. The same applies in reverse order for the shutdown-delay when shutting down a vApp.
vApps are the main reason for me to use XCP-ng Center.
For all my systems I always create a vAPP, which I call Start.
The start order for all VMs and the time delay are then stored here.
When you shut down, this list is automatically processed in reverse order.
vApps is one of the features I miss most in XenOrchestra.
If necessary, from XCP-ng 8.3 onwards I have to switch to the command line to work with vApps.
I also have the reboot problem.
It only occurs for me when a USB hard drive is connected.
If there is no hard drive connected to the USB interfaces, the system will run stable for months / years.
Today I had to read data into a VM via USB hard drive, so I connected one.
I haven't had any problems during the data transfer so far. Only when the USB hard drive is no longer used and is still connected..
Please check whether something is connected via USB on the systems that have the reboot problem.
I've had this problem on other systems too. But it never bothered me because I don't normally have anything connected to the USB ports.
I also had the reboot problem in earlier versions of xcp-ng or Xenserver and it also occurred on HP servers that I used before I switched to Supermicro.
I have been using Xenserver since version 5.0.
Mainboard: Supermicro H11SSL-i BIOS 2.4
CPU: Epyc 7551P