Questo contenuto non è disponibile nella lingua selezionata.
Chapter 28. Virtualization
Limited CPU support for Windows 10 and Windows Server 2016 guests
On a Red Hat Enterprise 6 host, Windows 10 and Windows Server 2016 guests can only be created when using the following CPU models:
- the Intel Xeon E series
- the Intel Xeon E7 family
- Intel Xeon v2, v3, and v4
- Opteron G2, G3, G4, G5, and G6
For these CPU models, also make sure to set the CPU model of the guest to match the CPU model detected by running the
virsh capabilities command on the host. Using the application default or hypervisor default prevents the guests from booting properly.
To be able to use Windows 10 guests on Legacy Intel Core 2 processors (also known as Penryn) or Intel Xeon 55xx and 75xx processor families (also known as Nehalem), add the following flag to the Domain XML file, with either Penryn or Nehalem as MODELNAME:
<cpu mode='custom' match='exact'> <model>MODELNAME</model> <feature name='erms' policy='require'/> </cpu>
Other CPU models are not supported, and both Windows 10 guests and Windows Server 2016 guests created on them are likely to become unresponsive during the boot process. (BZ#1252134)
Resizing VHDX files can take a very long time
When an ext3 file system is being used in the guest, resizing very large Microsoft Hyper-V virtual hard disk (VHDX) devices in some cases causes the VHDX file to grow to an excessive size, and thus takes significantly longer than intended. To work around this problem, use ext4 or xfs file systems, or set the following custom parameters when creating VHDX files:
- VHDX BlockSize = 1MB
- flex_bg=4096
These ensure that VHDX files require the expected amount of disk space, which in turn makes file system operations much faster. (BZ#1024137)
Multifunction does not work correctly when hot-plugging virtual PCI devices
Hot-plugging a new function on a virtual PCI device that has the multifunction option enabled does not correctly trigger PCI device initialization. As a consequence, the guest does not recognize the hot-plugged function, and thus cannot use it. To work around this problem, initiate a rescan of the PCI Host Bridge in the guest, for example with the following command:
# echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/rescan
In the above example, replace 0000\:00\:00.0 with the correct bus:device:function combination of the device you wish to rescan.
This forces the guest device drivers to configure newly hot-plugged devices for use, and thus makes the function available. (BZ#1208430)
Soft-rebooted Windows guests cannot detect some of their bootable devices
Under certain circumstances, soft-rebooting a Windows guest (for example by using the Ctrl+Alt+Del keys) causes the guest not to detect some of its bootable devices. To work around this problem, perform a hard reboot of the guest - for example by the Shutdown button in the virt-manager interface, or by the
system_reset command in the QEMU monitor console. (BZ#1129549)
Using qemu-img to modify an image that is in use can corrupt the image
Opening a QEMU disk image from multiple processes at the same time, for example by attempting to take a snapshot of a QEMU image while the guest is running, in some cases corrupts the image. To avoid this problem, never use the qemu-img utility to modify images in use by a running virtual machine or any other process. In addition, be aware that querying an image that is being modified by another process may trigger an inconsistent state error. This update also adds an admonition about the mentioned problem to the qemu-img(1) man page. (BZ#1297424)
virtio-win VFD files do not contain Windows 10 drivers
Due to limitations on the floppy device file size, the virtual floppy disk (VFD) files in the virtio-win packages do not contain a Windows 10 folder. If you need to install Windows 10 drivers from a VFD, use the Windows 8 or Windows 8.1 drivers instead. Alternatively, the Windows 10 drivers can be installed from the ISO file in the
/usr/share/virtio-win/ directory. (BZ#1315940)
Booting virtual machines with the fsgsbase and smep flags on older host CPUs fails
The
fsgsbase and smep CPU flags are not properly emulated on certain older CPU models, such as the early Intel Xeon E processors. As a consequence, using fsgsbase and smep when booting a Windows guest virtual machine on a host with one of the described CPUs causes the boot to fail. Similarly, using smep when booting a Red Hat Enterprise Linux guest virtual machine on a host with one of the described CPUs causes the boot to fail. To work around this problem, do not use fsgsbase and smep if the CPU does not support them. (BZ#1371765)
