6 Supported Hosts, Guests, and Features #
Supported architectures and virtualization limits for Xen and KVM are outlined in the Release Notes.
6.1 Host Environments (Hypervisors) #
This section lists the support status of SUSE Linux Enterprise Server 15 SP2 running as a guest on top of various virtualization hosts (Hypervisor).
SLES 11 SP4
SLES 12 SP1, SP2, SP3, SP4, SP5
SLES 15 SP0, SP1, SP2
VMware ESXi 6.5, 6.7
Microsoft Windows 2008 R2 SP1+, 2012+, 2012 R2+, 2016, 2019
Citrix XenServer 7.0, 7.1, 8.0
Oracle VM 3.4
Nutanix Acropolis Hypervisor with AOS 5.8
Support for SUSE host operating systems is full L3, both for the guest and host.
Support for third party host environments is full L3 for the guest and needs the host vendor cooperation and support for the host.
6.2 Guest Environments #
This section lists the support status for various guest operating systems virtualized on top of SUSE Linux Enterprise Server 15 SP2. All guest operating systems are supported both fully-virtualized (“FV” in the following table) and paravirtualized (“PV” in the following table) with two exceptions: Windows, which is only supported fully-virtualized, and NetWare operating systems, which are only supported on Xen paravirtualized. All guest operating systems are supported both in 32-bit and 64-bit flavors, unless stated otherwise (see NetWare).
Microsoft Windows guests can be rebooted by libvirt/virsh only if paravirtualized
drivers are installed in the guest. Refer to
https://www.suse.com/products/vmdriverpack/ for more
details on downloading and installing PV drivers.
SLES 10 SP4
SLES 11 SP3, SP4
SLES 12 SP0, SP1, SP2, SP3, SP4, SP5
SLES 15 SP0, SP1, SP2
OES 11 SP2, 2015, 2015 SP1, 2018, 2018 SP1, 2018 SP2
NetWare 6.5 SP8 (32-bit only)
Windows Server 2008 SP2+, 2008 R2 SP1+, 2012+, 2012 R2+, 2016, 2019
SLED 15 SP1
Refer to the SUSE Liberty Linux documentation at https://documentation.suse.com/liberty for the list of available combinations and supported releases. In other cases, they are supported on a limited basis (L2, fixes if reasonable).
Windows 8+, 8.1+, 10+
6.2.1 Availability of Paravirtualized Drivers #
To improve the performance of the guest operating system, paravirtualized drivers are provided when available. Although they are not required, it is strongly recommended to use them. The paravirtualized drivers are available as follows:
- SUSE Linux Enterprise Server 12 / 12 SP1 / 12 SP2
Included in kernel
- SUSE Linux Enterprise Server 11 / 11 SP1 / 11 SP2 / 11 SP3 / 11 SP4
Included in kernel
- SUSE Linux Enterprise Server 10 SP4
Included in kernel
- Red Hat
Available in Red Hat Enterprise Linux 5.4 and newer
- Windows
SUSE has developed virtio-based drivers for Windows, which are available in the Virtual Machine Driver Pack (VMDP). For more information, see https://www.suse.com/products/vmdriverpack/.
6.3 KVM Hardware Requirements #
Currently, SUSE supports KVM full virtualization on AMD64/Intel 64 and AArch64 hosts, and on IBM Z.
On the AMD64/Intel 64 architecture, KVM is designed around hardware virtualization features included in AMD* (AMD-V) and Intel* (VT-x) CPUs. It supports virtualization features of chipsets and PCI devices, such as an I/O Memory Mapping Unit (IOMMU) and Single Root I/O Virtualization (SR-IOV). You can test whether your CPU supports hardware virtualization with the following command:
>egrep '(vmx|svm)' /proc/cpuinfoIf this command returns no output, your processor either does not support hardware virtualization, or this feature has been disabled in the BIOS or firmware.
The following Web sites identify AMD64/Intel 64 processors that support hardware virtualization: http://ark.intel.com/Products/VirtualizationTechnology (for Intel CPUs), and http://products.amd.com/ (for AMD CPUs).
On the Arm architecture, virtualization support was initially added to Armv7-A processors starting with Arm Cortex-A15 and including Cortex-A7 and Cortex-A17. Armv8-A processors include support for virtualization.
The KVM kernel modules only load if the CPU hardware virtualization features are available.
The general minimum hardware requirements for the VM Host Server are the same as outlined in 2.1項 「ハードウェア要件」. However, additional RAM for each virtualized guest is needed. It should at least be the same amount that is needed for a physical installation. It is also strongly recommended to have at least one processor core or hyper-thread for each running guest.
6.4 Feature Support #
6.4.1 Host (Dom0) #
Dom0) #|
Features |
Xen |
|---|---|
|
Network and block device hotplugging |
Yes |
|
Physical CPU hotplugging |
No |
|
Virtual CPU hotplugging |
Yes |
|
Virtual CPU pinning |
Yes |
|
Virtual CPU capping |
Yes |
|
Intel* VT-x2: FlexPriority, FlexMigrate (migration constraints apply to dissimilar CPU architectures) |
Yes |
|
Intel* VT-d2 (DMA remapping with interrupt filtering and queued invalidation) |
Yes |
|
AMD* IOMMU (I/O page table with guest-to-host physical address translation) |
Yes |
The addition or removal of physical CPUs at runtime is not supported. However, virtual CPUs can be added or removed for each VM Guest.
6.4.2 Paravirtualized Guest #
|
Features |
Xen |
|---|---|
|
Virtual network and virtual block device hotplugging |
Yes |
|
Virtual CPU hotplugging |
Yes |
|
Virtual CPU over-commitment |
Yes |
|
Dynamic virtual memory resize |
Yes |
|
VM save and restore |
Yes |
|
VM live migration |
Yes, between like virtual host systems with similar resources |
|
Advanced debugging with GDBC |
Yes |
|
Dom0 metrics visible to VM |
Yes |
|
Memory ballooning |
Yes |
|
PCI pass-through |
Yes (NetWare guests are excluded) |
For live migration, both source and target system architectures need to match; that is, the processors (AMD* or Intel*) must be the same. Unless CPU ID masking is used, such as with Intel FlexMigration, the target should feature the same processor revision or a more recent processor revision than the source. If VMs are moved among different systems, the same rules apply for each move. To avoid failing optimized code at runtime or application start-up, source and target CPUs need to expose the same processor extensions. Xen exposes the physical CPU extensions to the VMs transparently. To summarize, guests can be 32-bit or 64-bit, but the VHS must be identical.
For machines that support Intel FlexMigration, CPU-ID masking and faulting allow more flexibility in cross-CPU migration.
6.4.3 Fully Virtualized Guest #
|
Features |
Xen |
KVM |
|---|---|---|
|
Virtual network and virtual block device hotplugging |
Yes |
Yes |
|
Virtual CPU hotplugging |
No |
No |
|
Virtual CPU over-commitment |
Yes |
Yes |
|
Dynamic virtual memory resize |
Yes |
Yes |
|
VM save and restore |
Yes |
Yes |
|
VM Live Migration |
Yes between like virtual host systems with similar resources (that is, from 32-bit to 32-bit, 64-bit to 64-bit) |
Yes |
|
VM snapshot |
Yes |
Yes |
|
Advanced debugging with GDBC |
Yes |
Yes |
|
Dom0 metrics visible to VM |
Yes |
Yes |
|
PCI pass-through |
Yes |
Yes |
Hotplugging of virtual network and virtual block devices, and resizing, shrinking, and restoring dynamic virtual memory are supported in Xen and KVM only if PV drivers are being used (VMDP).
For KVM, a detailed description of supported limits, features,
recommended settings and scenarios, and other useful information is
maintained in kvm-supported.txt. This file is part of
the KVM package and can be found in
/usr/share/doc/packages/qemu-kvm.