SLES 12 SP5 released

SLES 12 SP5 is out! See this section in the release notes for a detailed look at IBM Z-specific changes in support of KVM.
Otherwise, the update ships the following code levels:

• Linux kernel 4.12 (SP4: 4.12, unchanged),
• QEMU v3.1 (SP4: v2.11), and
• libvirt v5.1 (SP4: v4.0).

See previous blog entries on QEMU v2.12 and v3.0, and libvirt v4.7 and v4.10 for further details on new features that become available by the respective package updates.
Also take note of this article, which adds further details on IBM z15 support.

Documentation: New Performance Papers

Two new performance papers on KVM network performance were published:

• Best Practices and Tuning Recommendations
• Exploitation of IP Routing

See also the Performance Hot topics page in IBM Knowledge Center.

QEMU v4.2 released

QEMU v4.2 is out. For highlights from a KVM on Z perspective see the Release Notes.

Webinar: Dynamically provisioning resources to KVM hosted Linux virtual servers

Abstract
Are you just getting started with KVM? In this session we review dynamic provisioning and de-provisioning processor, memory, disk storage, and network connectivity to your KVM host and the guest virtual servers. Examples include both graphical management and command line interfaces. Come and see how simple it can be to manage your servers.

Speaker
Richard Young, Executive IT Specialist, IBM Systems

Registration
Register here. You can check the system requirements here.
After registering, you will receive a confirmation email containing information about joining the webinar.

Replay & Archive
All sessions are recorded. For the archive as well as a replay and handout of this session and all previous webcasts see here.

Documentation: KVM Virtual Server Management Update

Intended for KVM virtual server administrators, this book illustrates how to set up, configure, and operate Linux on KVM instances and their virtual devices running on the KVM host and IBM Z hardware.

This major update includes information about VFIO pass-through devices, virtual server setup with the virt-install command, setting up virtual switches with VNIC characteristics, and other features that are available with the latest versions of QEMU and libvirt.

You can download the .pdf here.

Ubuntu 19.10 released

Ubuntu Server 19.10 is out!
It ships

• Linux kernel 5.3,
• QEMU v4.0, including support for the IBM z15 CPU model
• libvirt v5.4.

For a detailed list of KVM on Z changes, see the release notes here.

KVM on IBM z15 Features

To take advantage of the new features of z15, the latest addition to the IBM Z family as previously announced here, use any of the following CPU models in your guest's domain XML:

• Pre-defined model for z15
    <cpu mode='custom'>
      <model>gen15a</model>
    </cpu>
• Use z15 features in a migration-safe way (recommended). E.g. when running on z15 this will be a superset of the gen15a model, and feature existence will be verified on the target system prior to a live migration:
    <cpu mode='host-model'/>
• Use z15 features in a non-migration-safe way. I.e. feature existence will not be verified on the target system prior to a live migration:
    <cpu mode='host-passthrough'/>

Here is a list of features of the new hardware generation as supported in Linux kernel 5.2 and QEMU 4.1, all activated by default in the CPU models listed above:

• Miscellaneous Instructions
  Following the example of previous machines, new helper and general purpose instructions were
    minste3     Miscellaneous-Instruction-Extensions Facility 3 
• SIMD Extensions
  Following up to the SIMD instructions as introduced with the previous z13 and z14 models, this feature again provides further vector instructions, which can again be used in KVM guests.
  These new vector instructions can be used to improve decimal calculations as well as for implementing high performance variants of certain cryptographic operations.
  In the z15 CPU models, the respective feature is:
    vxpdeh      Vector-Packed-Decimal-Enhancement Facility
    vxeh2       Vector enhancements facility 2 
• Deflate Conversion
  Provide acceleration for zlib compression and decompression
  In the z15 CPU model, the respective feature is:
    dflt        Deflate conversion facility
• MSA Updates
  z15 introduces a new Message Security Assist MSA9, providing elliptic curve cryptography. It supports message authentication, the generation of elliptic curve keys, and scalar multiplication.
  This feature can be exploited in KVM guests' kernels and userspace applications independently (i.e. a KVM guest's userspace applications can take advantage of these features irrespective of the guest's kernel version).
  In the z15 CPU model, the respective feature is:
    msa9        Message-security-assist-extension 9 facility
    msa9_pckmo  Message-security-assist-extension 9 PCKMO
                subfunctions for protected ECC keys

The z15 CPU model was backported into several Linux distributions. It is readily available in RHEL8.1, SLES 12 SP5, SLES 15 SP1 (via maintweb updates for kernel and qemu) and Ubuntu 18.04.

IBM z15 announced

Today, IBM announced the new IBM Z models:

• IBM z15: See the official announcement for EMEA here, and for the US here.
• LinuxONE III: See the official announcement here.

Furthermore, check the updated IBM Z tested platforms matrix here.
We will look at features in support of the new IBM Z model in a separate blog entry soon.

virt-manager 2.2 released

virt-manager v2.2 was released a while ago. One feature we contributed is the ability to choose a temporary boot device. Here is a quick write-up on how to use that feature.

virt-xml is a simple command line tool for editing domain definitions. It can be used interactively or for batch processing. Starting with virt-manager v2.2, virt-xml allows to boot a guest with a temporarily changed domain definition. This allows us to specify a boot configuration other than the guest's current domain definition. This is especially useful as the IBM Z architecture allows for only a single boot device, and therefore the boot order settings do not work the way they do on other platforms: If the first boot device fails to boot, there is no attempt made to boot from the next boot device. In addition, the architecture/BIOS has no support for interactively changing the boot device during the boot/IPL process.
Therefore, two new command line options were introduced:

• --no-define makes any changes to the domain definition transient (i.e. the guest's persistent domain XML will not be modified)
• --start allows the user to start the domain after the changes to the domain XML were applied

Here is a simple example illustrating the usage:

1. First, select the device which should be changed by a selector. In this example, the unique target name of the disk is used. See man virt-xml for a list of further possibilities.
2. Temporarily modify the boot order, assign the first slot to device vdc, and start the guest right away:
   
     $ virt-xml --edit target='vdc' --disk='boot_order=1' --start \
                --no-define sample_domain
   Note: If there was another device that already had boot_order=1, its boot order would be incremented.

As soon the guest is stopped, the changes will vanish.

Webinar: How to Virtualize with KVM in Live Demo, August 28

Abstract
We will explain basic KVM concepts, including CPU and memory virtualization, storage, network management, as well as a brief overview about commonalities and differences with other virtualization environments. Furthermore, a live demo will demonstrate how to use the KVM management tools to create and install Linux guests, how to operate and monitor.

Speaker
Christian Bornträger, Chief Product Owner Linux and KVM on IBM Z.

Registration
Register here. You can check the system requirements here.
After registering, you will receive a confirmation email containing information about joining the webinar.

Replay & Archive
All sessions are recorded. For the archive as well as a replay and handout of this session and all previous webcasts see here.

QEMU v4.1 released

QEMU v4.1 is out. For highlights from a KVM on Z perspective see the Release Notes.
Note: The DASD IPL feature is still considered experimental.

New Documentation: Configuring Crypto Express Adapters for KVM Guests

See here for a new documentation release on how to configure Crypto Express adapters for KVM guests.

SLES 15 SP1 Released

SLES 15 SP1 is out! See the announcement and their release notes with Z-specific changes.
It ships the following code level updates:

• QEMU v3.1 (GA: v2.11)
• libvirt v5.1 (GA: v4.0)

See previous blog entries on QEMU v2.12, v3.0 and v3.1 for details on new features that become available with the QEMU package update.
Furthermore, SLES 15 SP1 introduces the kvm_stat tool, which can be used for guest event analysis.

KVM at SHARE Pittsburgh 2019

Yes, we will be at SHARE in Pittsburgh this August!
See the following session in the Linux and VM/Virtualization track:

• KVM on IBM Z News (Session #25978): Latest news on our development work with the open source community

RHEL 8 released

Red Hat Enterprise Linux 8 is out! See the announcement and their release notes with Z-specific changes.
It ships the following code levels:

• Linux kernel 4.18
• QEMU v2.12
• libvirt v4.5

QEMU v4.0 released

QEMU v4.0 is out. Besides a number of small enhancements, some items that we would like to highlight from a KVM on Z perspective:

• CPU models for z14 GA2 as follows:
     $ qemu-system-s390x -cpu help -enable-kvm | grep z14.2
     s390 z14.2-base      IBM z14 GA2           (static, migration-safe)
     s390 z14.2           IBM z14 GA2           (migration-safe)
• vfio-ap now supports hotplugging of vfio-ap devices.

libvirt v4.10 released, providing PCI passthrough support

libvirt v4.10, available for download at the libvirt project website, adds support for PCI passthrough devices on IBM Z (requires Linux kernel 4.14 and QEMU v2.11).
To setup passthrough for a PCI device, follow these steps:

1. Make sure the vfio-pci module is  available, e.g. using the modinfo command:
      $ modinfo vfio-pci
      filename:       /lib/modules/4.18.0/kernel/drivers/vfio/pci/vfio-pci.ko
      description:    VFIO PCI - User Level meta-driver
2. Verify that the pciutils package, providing the lspci command et al, is available using your distro's package manager
3. Determine the PCI device's address using the lspci command:
      $ lspci
      0002:06:00.0 Ethernet controller: Mellanox Technologies MT27500/MT27520 Family
                   [ConnectX-3/ConnectX-3 Pro Virtual Function] 
4. Add the following element to the guest domain XML's devices section:
      <hostdev mode='subsystem' type='pci' managed='yes'>
        <source>
          <address domain='0x0002' bus='0x06' slot='0x00' function='0x0'/>
        </source>
      </hostdev>
   Note that if attribute managed is set to no (which is the default), it becomes the user's duty to unbind the PCI device from the respective device driver, and rebind to vfio-pci in the host prior to starting the guest.

Once done and the guest is started, running the lspci command in the guest should show the PCI device, and one can proceed to configure it as needed.
It is well worth checking out the expanded domain XML:
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0002' bus='0x06' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0002' bus='0x00' slot='0x01' function='0x0'>
        <zpci uid='0x0001' fid='0x00000000'/>
      </address>
    </hostdev>
Theoretically, the PCI address in the guest can change between boots. However, the <zpci> element guarantees address persistence inside of the guest. The actual address of the passthrough device is based solely on the uid attribute: The uid becomes the PCI domain, all remaining values of the address (PCI bus, slot and function) are set to zero. Therefore, in this example, the PCI address in the guest would be 0001:00:00:0.
Take note of the fid attribute, whose value is required to hotplug/hotunplug PCI devices within a guest.
Furthermore note that the target PCI address is not visible anywhere (except within the QEMU process) at all. I.e. it is not related to the PCI address as observed within the KVM guest, and could be set to an arbitrary value. However, choosing the "wrong" values might have undesired subtle side effects with QEMU. Therefore, we strongly recommend not to specify a target address, and to rather rely on the auto-assignment. I.e. if the guest's PCI address has to be chosen, at a maximum restrict the target address element to uid (for PCI address definition) and fid (so that e.g. scripts in the guest for hotplugging PCI devices can rely on a specific value) as follows:
   <address type='pci'>
     <zpci uid='0x0001' fid='0x00000000'/>
   </address>

For further (rather technical) details see here and here (git commit).

Knowledge Series: CPU Models and Migration Considerations

Another new entry in our Knowledge Series explains CPU models and its relationship to live guest migration.