Configuring a DASD, SCSI, or NVMe disk

Edit online

You can configure DASDs, SCSI disks, and NVMe devices as virtio block devices in the configuration-XML.

Before you begin

Make sure that

If the virtual server uses Logical Volume Manager (LVM), be sure to exclude these devices from the host LVM configuration. Otherwise, the host LVM might interpret the LVM metadata on the disk as its own and cause data corruption. For more information, see Logical volume management.

About this task

You specify DASDs, FC-attached SCSI disks, and NVMe devices through device nodes. If you want to identify the device on the host as it appears to the virtual server, specify a device number for the virtual block device.

Procedure

  1. Configure the device.
    1. Configure the device as virtio block device.
      disk type attribute: block
      disk device attribute: disk
      (see <disk>)
    2. Specify the user space process that implements the device.
      driver name attribute: qemu
      driver type attribute: raw
      driver cache attribute: none
      driver io attribute: native
      driver iothread attribute: <IOthread-ID>
      (see <driver> as child element of <disk>)

      <IOthread-ID> assigns an I/O thread for I/O operations on the device.

      For devices that are defined in the domain configuration-XML file:
      Specify a value between 1 and the number of I/O threads configured by the iothreads element in the domain configuration-XML file.
      For devices that are defined in separate device configuration-XML files:
      Specify an existing I/O thread or use the virsh iothreadadd command to create a new one when the device is attached.
      Example: 
      <domain>
    ...
    <iothreads>2</iothreads>
    ...
    <devices>
        <disk type="block" device="disk">
            <driver name="qemu" type="raw" cache="none" io="native" 
            iothread="2"/>
            ...
        </disk>
    </devices>
    ....
</domain>
      In this example, I/O thread with ID 2 is assigned to perform the input operations to and the output operations from the device.
    3. For guests that are to run in IBM® Secure Execution mode and cannot use the launchSecurity element in the virtual server configuration, ensure that the device uses the guest's bounce buffer, see Preparing the virtual server.
    4. Specify virtio as the virtual server disk device type.
      target bus attribute: virtio
      (see <target> as child element of <disk>)
  2. Identify the device on the host.

    Specify a device node of the device.

    source dev attribute: <device-node>
    (see <source> as child element of <disk>)
    Note: You should be aware that the selection of the specified device node determines whether or not you will be able to:
    • Perform a live migration of the virtual server accessing the device.
    • Migrate the storage to another storage server or another storage controller.
    For DASDs:
    Use udev-created device nodes.

    All udev-created device nodes support live migration. By-uuid device nodes support also storage migration, because they are hardware-independent.

    For SCSI disks:
    Use device mapper-created device nodes.

    Device mapper-created device nodes are unique and always specify the same device, irrespective of the host which runs the virtual server.

    Please be aware that setting up multipathing on the host without passing the device mapper-created device nodes to the virtual server leads to the loss of all multipath advantages regarding high availability and performance.

    For NVMe devices:
    Use udev-created persistent device nodes.

    For live migration of a virtual server, device nodes must be such that they addresses equivalent resources on both the source and destination host. Migration of the virtio block device is then possible through disk migration, see step 3.c in Performing a live migration.

  3. Identify the device on the virtual server.
    1. Specify a unique logical device name.

      Logical device names are of the form vd<x>, where <x> can be one or more letters. Do not confuse the logical device name with the standard device name. The standard device name is assigned to the device on the virtual server in the order the device is detected. It is not persistent across guest reboots.

      target dev attribute: <logical-device-name>
      (see <target> as child element of <disk>)
    2. Optional: Specify a unique device number.
      You specify a device bus-ID, which is of the form 
      fe.n.dddd
      where n is the subchannel set-ID and dddd is the device number. The channel subsystem-ID 0xfe is reserved to the virtual channel.

      The virtual server sees the channel subsystem-ID 0x0 instead.

      Tip: Do not mix device specifications with and without device numbers.
      address type attribute: ccw
      address cssid attribute: 0xfe

      (reserved channel subsystem-ID)
      address ssid attribute: <subchannel-set-ID>
      address devno attribute: <device-number>
      (see <address> as child element of <controller>, <disk>, <filesystem>, and <memballoon>)
      Example: KVM host device bus-ID fe.0.1a12 is seen by the virtual server as device bus-ID 0.0.1a12.

      If you do not specify a device number, a device bus-ID is automatically generated by using the first available device bus-ID starting with subchannel set-ID 0x0 and device number 0x0000.

      Assign device numbers depending on your policy, such as:
      • Assigning identical device numbers on the virtual server and on the host enable the virtual server user to identify the real device.
      • Assigning identical device numbers on the virtual servers allows you to create identical virtual servers.