Known issues
UCS-4.2 shipps with the newer QEMU version 2.8, which is currently incompatible with the QEMU version 1.1 previously used until UCS-4.1. Symptoms include
- guest operating systems gets stuck in a busy-loop using 100% virtual CPU time
- virtual machine reboots
- virtual machine does not reboot after shutdown request
This can happen after
- restoring the virtual machine from the suspend-to-disk state
- restoring the virtual machine from a snapshot taken from a running system
- live-migration from a UCS-4.1 (or older) system
Univention is working on this problem and will provide updated packages and information when the issue is fixed.
Mitigation
If possible, servers running the 'KVM virtualization server' app can simply stay on UCS 4.1 until Univention releases a fix for the UCS 4.2 QEMU version. All features will remain functional when controlling virtual machies via UVMM.
If the UCS servers running the'KVM virtualization server' app have to be updated to UCS 4.2, the issues can be mitigated by
- shutting down all virtual machines cleanly before performing the update
- upgrading the virtual machine hardware configuration
- creating and using snapshots only of cleanly shut down virtual machines
- migrating only shut down virtual machines between hosts using different UCS releases
All of these options must be performed before a virtual machine is migrated or the host system is updated. If this is not possible the virtual machine might crash, which can lead to data loss (only the state of the RAM, not the data on disk). After such a runtime crash the guest operating system usually performs a file system check to recover consistency. For snapshots this process can be repeated multiple times, but not for live migration and suspend, as the runtime state there is only available once.
Univention also has observed problems with virtual machines not rebooting properly: virtual machines running the Linux operating system display the message "reboot: Restarting system" last while systems running Microsoft Windows are stuck on the reboot screen. This can be mitigated by upgrading the virtual machine hardware configuration, which is described below.
How can I find virtual machines suspended to disk?
You can run the command "virsh list --all --with-managed-save".
As an alternative you can directly look at the file systeme level: for each VM there exists a file "/var/lib/libvirt/qemu/save/$VM.save".
How can I remove the managed save state of a virtual machine suspended to disk, if I prefer to start the VM in a crashed state instead of not starting it at all?
Run 'virsh managedsave-remove $VM"
How can I reset a virtual machine if it is not responding after restoring the running state?
Try "virsh restart $VM" to trigger a reboot. This will re-use the running QEMU process.
If that does not work, stop it with "virsh destroy $VM" and start it with "virsh start $VM" again. This will create a new QEMU process, which reload all files from disk.
What is a virtual machine hardware configuration and how can I upgrade it?
Each QEMU version can emulate different PC hardware. UVMM uses the latest version provided by the currently installed QEMU version. Until UCS-4.1 this was "pc-1.1", since UCS-4.2 this is "pc-i440fx-2.8". All supported architectures can be seen by calling qemu-system-x86_64 -M help
Newer versions of both also use a different BIOS/firmware, which supports (U)EFI.
The libvirt XML description of a virtual machine references these machine definitions, to provide a stable environment even when newer versions of QEMU are used. Otherwise operating systems like Microsoft Windows may complain about changed hardware and might require reactivating their licence. To see which hardware configuration a machine uses, the configuration can be inspected by by running "virsh dumpxml $VM" and looking for the line "<type arch="..." machine="..."/>":
<domain type='kvm'>
...
<os>
<type arch='x86_64' machine='pc-i440fx-2.8'>hvm</type>
...
</os>
...
</domain>
A virtual machine hardware configuration can be upgraded manually by running "virsh edit $VM" and chaning the machine attribute to "pc-i440fx-2.8" as shown in the example above.