5.13. kernel-xen


  • Migrating a guest that is using the xen-vnif drivers as a fully virtualized guest under Xen will produce a deadlock in the XenBus. This bug, however, does not present if the IOEMU driver is used or if the system has no active network interface. (BZ#555910)
  • On Intel platforms with VT-d enabled, the frame buffer of a fully-virtualized Xen guest with 4GB or more RAM might not be displayed correctly. To work around this issue, create the guest with additional memory (e.g. 2GB more than desired), close the guest, then recreate the guest with the desired amount of RAM. (BZ#511398)
  • Xen guests will not boot using configurations that bind multiple virtualized CPUs to a single CPU. (BZ#570056)
  • The Xen hypervisor will not start when booting from an iSCSI disk. To work around this issue, disable the Xen hypervisor's EDD feature with the "edd=off" kernel parameter. For example:
    kernel /xen.gz edd=off
    
    (BZ#568336)
  • Some BIOS implementations initialize interrupt remapping hardware in a way that Xen does not expect. Consequently, a system might hang during boot, returning the error message:
    (XEN) [VT-D]intremap.c:73: remap_entry_to_ioapic_rte: index (74) is larger than remap table entry size (55)!
    
    To work around this issue, disable the interrupt remapping feature in the BIOS and reboot the system. (BZ#563546)
  • blktap may not function as expected, resulting in slow disk I/O causing the guest to operate slowly also. To work around this issue guests should be installed using a physical disk (i.e. a real partition or a logical volume). (BZ#545692)
  • On certain platforms, the mptsas driver may cause kernel warning messages such as the following to be displayed:
      kernel unaligned access to 0xe0000034f327f0ff, ip=0xa0000002040c4870
      kernel unaligned access to 0xe0000034f327cbff, ip=0xa0000002040c4870
      kernel unaligned access to 0xe00000300c9581ff, ip=0xa0000002040c4870
    
    These messages do not indicate a serious error. The data alignment issue will be fixed in a future release. BZ#570000
  • When booting paravirtualized guests that support gigabyte page tables (i.e. a Fedora 11 guest) on Red Hat Enterprise Linux 5.4 Xen, the domain may fail to start if more than 2047MB of memory is configured for the domain. To work around this issue, pass the "nogbpages" parameter on the guest kernel command-line. (BZ#502826)
  • Boot parameters are required to enable SR/IOV Virtual Function devices. SR/IOV Virtual Function devices can only be accessed if the parameter pci_pt_e820_access=on is added to the boot stanza in the /boot/grub/grub.conf file. For example:
    title Red Hat Enterprise Linux Server (2.6.18-152.el5xen)
            root (hd0,1)
            kernel /xen.gz-2.6.18-152.el5 com1=115200,8n1 console=com1 iommu=1
            module /vmlinuz-2.6.18-152.el5xen ro root=LABEL=/ console=ttyS0,115200
    pci_pt_e820_access=on
    
    This enables the MMCONF access method for the PCI configuration space, a requirement for VF device support
  • When using Single Root I/O Virtualization (SR-IOV) devices under Xen, a single Hardware Virtual Machine (HVM) guest is limited to 12 Virtual Function (VF) assignments. (BZ#511403)
  • When booting a fully virtualized Xen guest, the following message may be displayed on the guest console:
    testing NMI watchdog ... <4>
    WARNING: CPU#0: NMI appears to be stuck (0->0)!
    
    This issue is caused by an implementation issue with the Xen hypervisor and can be safely ignored. (BZ#500845)
  • Diskette drive media will not be accessible when using the virtualized kernel. To work around this, use a USB-attached diskette drive instead.
    Note that diskette drive media works well with other non-virtualized kernels. (BZ#401081)
  • Formatting a disk when running Windows 2008 or Windows Vista as a guest can crash when the guest has been booted with multiple virtual CPUs. To work around this, boot the guest with a single virtual CPU when formatting. (BZ#441627)
  • Fully virtualized guests cannot correct for time lost due to the domain being paused and unpaused. Being able to correctly track the time across pause and unpause events is one of the advantages of paravirtualized kernels. This issue is being addressed upstream with replaceable timers, so fully virtualized guests will have paravirtualized timers. Currently, this code is under development upstream and should be available in later versions of Red Hat Enterprise Linux. (BZ#422531)
The following note applies to x86_64 Architectures:
  • Upgrading a host (dom0) system to Red Hat Enterprise Linux 5.2 may render existing Red Hat Enterprise Linux 4.5 SMP paravirtualized guests unbootable. This is more likely to occur when the host system has more than 4GB of RAM.
    To work around this, boot each Red Hat Enterprise Linux 4.5 guest in single CPU mode and upgrade its kernel to the latest version (for Red Hat Enterprise Linux 4.5.z). (BZ#253087, BZ#251013)
The following note applies to the ia64 Architecture:
  • On some Itanium systems configured for console output to VGA, the dom0 virtualized kernel may fail to boot. This is because the virtualized kernel failed to properly detect the default console device from the Extensible Firmware Interface (EFI) settings.
    When this occurs, add the boot parameter console=tty to the kernel boot options in /boot/efi/elilo.conf. (BZ#249076)
  • On some Itanium systems (such as the Hitachi Cold Fusion 3e), the serial port cannot be detected in dom0 when VGA is enabled by the EFI Maintenance Manager. As such, you need to supply the following serial port information to the dom0 kernel:
    • Speed in bits/second
    • Number of data bits
    • Parity
    • io_base address
    These details must be specified in the append= line of the dom0 kernel in /boot/efi/elilo.conf. For example:
    append="com1=19200,8n1,0x3f8 -- quiet rhgb console=tty0 console=ttyS0,19200n8"
    In this example, com1 is the serial port, 19200 is the speed (in bits/second), 8n1 specifies the number of data bits/parity settings, and 0x3f8 is the io_base address. (BZ#433771)
  • Virtualization does not work on some architectures that use Non-Uniform Memory Access (NUMA). As such, installing the virtualized kernel on systems that use NUMA will result in a boot failure.
    Some installation numbers install the virtualized kernel by default. If you have such an installation number and your system uses NUMA and does not work with kernel-xen, deselect the Virtualization option during installation. (BZ#293071)
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.