Virtualization on SUSE Linux with benefits and setup

You can install all the tools required for virtualization during the installation of SUSE Linux Enterprise Server for SAP applications on the VM Host Server. During the installation, you are presented with the System Role screen.

Figure 3: System Role screen #

 

Here you can select the KVM Virtualization Host role. The appropriate software selection and setup is automatically performed during SUSE Linux Enterprise Server for SAP applications installation.

Tip

Both virtualization system roles create a dedicated /var/lib/libvirt partition, and enable the firewalld and Kdump services.

Related software packages from SUSE Linux Enterprise Server for SAP applications software repositories are organized into installation patterns. You can use these patterns to install specific virtualization components on an already running SUSE Linux Enterprise Server for SAP applications. Use zypper to install them:

zypper install -t pattern PATTERN_NAME

To install the KVM environment, consider the following patterns:

If you use VMware ESX as a guest hypervisor on top of a KVM bare metal hypervisor, you may experience unstable network communication. This problem occurs especially between nested KVM guests and the KVM bare metal hypervisor or external network. The following default CPU configuration of the nested KVM guest is causing the problem:

<cpu mode='host-model' check='partial'/>

To fix it, modify the CPU configuration as follow:

[...]
<cpu mode='host-passthrough' check='none'>
 <cache mode='passthrough'/>
</cpu>
[...]

Mount the SLE VMDP ISO and run the virt-v2v-vmdp.sh script from the v2v_scripts directory:

The script performs the following actions:

Important: Do not manually copy driver files

Manual extraction and copying of VMDP files to /usr/share/virt-tools/ or /usr/share/virtio-win/ is not recommended. The directory structure expected by virt-v2v on SLES for SAP 16.0 differs from earlier versions. Always use the virt-v2v-vmdp.sh script to ensure the correct layout.

To define the converted VM directly in libvirt, use -o libvirt:

> sudo virt-v2v -i vmx /path/to/windows2022.vmx \
  -o libvirt -of qcow2 -os default \
  --network vm-network:default

The -os parameter specifies a libvirt storage pool name. Ensure the pool exists and has sufficient free space before running the conversion.

If virt-v2v fails with:

virt-v2v: error: libguestfs error: inspect_os: internal error:
inspect_os: unhandled exception thrown: Hivex.Error

This error occurs when libguestfs cannot parse the Windows registry hive files. Possible causes and resolutions:

If you see the warning:

virt-v2v: warning: there are no virtio drivers available for this
version of Windows (10.0 x86_64 Server win2k22).  virt-v2v looks
for drivers in /usr/share/virtio-win

This means virt-v2v could not find the virtio drivers for the detected Windows version. The guest will be configured with slower emulated devices instead of virtio.

Resolution: run the virt-v2v-vmdp.sh script from the SLE VMDP ISO. The script installs drivers in the correct directory layout. On SLES 16, the expected driver path for Windows Server 2022 is /usr/share/virtio-win/drivers/amd64/2k22/.

Important: Do not manually create symlinks as a workaround

While creating a symbolic link from 2k22 to another driver directory (e.g., win11) may suppress the warning, it is not a supported configuration. Always use the virt-v2v-vmdp.sh script with an up-to-date SLE VMDP ISO.

After converting Windows Server 2019, 2022, or 2025, the VM may fail to boot with an “Inaccessible Boot Device” error or a page fault blue screen.

This issue is caused by the virtio block driver installation path. On these Windows versions, the VMDP setup installs the updated virtio block driver to the driver store directory (\windows\system32\driverstore\filerepository) using DIRID 13, while removing the driver from \windows\system32\drivers (DIRID 12). Windows fails to locate the block driver on next boot.

Resolution: ensure you are using a recent SLE VMDP ISO version (2.5 or later) that includes the fix. The updated VMDP setup.exe copies the driver to both locations, allowing the VM to boot correctly.

If the VM fails to boot with an older VMDP version, you can manually copy the virtio block driver from the driver store to \windows\system32\drivers to restore boot capability.

If the --network mapping fails, the converted VM may not have a correctly configured network interface. To resolve:

To enable verbose output for debugging, run virt-v2v with the -v option:

> sudo virt-v2v -v -i vmx /path/to/vm.vmx -o local -of qcow2 -os /output/dir

For additional libguestfs debugging, set:

> export LIBGUESTFS_DEBUG=1

> export LIBGUESTFS_TRACE=1

The VMDP ISO can be loaded as a virtual CD in a KVM VM to provide VirtIO Block or SCSI drivers during Windows installation. On the Where do you want to install Windows screen, select Load driver and follow the prompts to select the appropriate driver.

The ISO also contains the full VMDP setup.exe along with expanded contents for installation flexibility. These can be used for both Xen and KVM hosted Windows VMs.