[libvirt] [PATCH v3 03/17] conf: Add <disk model='virtio-{non-}transitional'/>

Andrea Bolognani abologna at redhat.com
Tue Feb 12 14:29:35 UTC 2019


On Fri, 2019-02-08 at 17:11 -0500, Cole Robinson wrote:
[...]
> +++ b/docs/formatdomain.html.in
> @@ -2922,6 +2922,17 @@
>              <span class="since">Since 0.1.4</span>
>              </p>
>              </dd>
> +          <dt><code>model</code></dt>
> +            <dd>
> +            Indicates the emulated device model of the disk. Typically
> +            this is indicated solely by the <code>bus</code> property but
> +            for <code>bus</code> "virtio" the model can be specified further
> +            with "virtio-transitional", "virtio-non-transitional", or
> +            "virtio", see

s/, see/. See/

[...]
> +      <dt><code>virtio-transitional</code></dt>
> +      <dd>This instructs libvirt to always place the device in a conventional
> +      PCI slot. The device can work with a virtio 0.9 or virtio 1.0
> +      guest driver.
> +      </dd>

I'd reword this a bit to highlight the fact that protocol
compatibility is the main point of these devices, and slot assignment
stems from it. Something like

  This device can work both with virtio 0.9 and virtio 1.0 guest
  drivers, so it's the best choice when compatibility with older
  guest operating systems is desired. libvirt will plug the device
  into a conventional PCI slot.

> +      <dt><code>virtio-non-transitional</code></dt>
> +      <dd>
> +      The device can only work with a virtio 1.0 guest driver.

In the same vein as the above,

  This device can only work with virtio 1.0 guest drivers, and it's
  the recommended option unless compatibility with older guest
  operating systems is necessary. libvirt will plug the device into
  either a PCI Express slot or a conventional PCI slot based on the
  machine type, resulting in a more optimized PCI topology.

> +      </dd>
> +      <dt><code>virtio</code></dt>
> +      <dd> If the device is plugged into a PCIe slot, it acts as a
> +      virtio-non-transitional device. If plugged into a conventional PCI slot,
> +      it will function as a virtio-transitional device. This logic only
> +      applies to devices that support the transitional models; for other
> +      devices, <code>virtio</code> behavior will be different.

And here too,

  This device will work like a <code>virtio-non-transitional</code>
  device when plugged into a PCI Express slot, and like a
  <code>virtio-transitional</code> device otherwise; libvirt will
  pick one or the other based on the machine type. This is the best
  choice when compatibility with libvirt versions older than 5.1.0
  is necessary, but it's otherwise not recommended to use it.

The idea behind these suggestions is that we should help the user
understand the various trade-offs and pick the value that better
suits their needs.

[...]
> +++ b/tests/qemuxml2argvdata/virtio-non-transitional.xml
> @@ -0,0 +1,17 @@
> +<domain type='qemu'>
> +  <name>QEMUGuest1</name>
> +  <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
> +  <memory unit='KiB'>219136</memory>
> +  <os>
> +    <type arch='x86_64' machine='q35'>hvm</type>
> +  </os>
> +  <devices>
> +    <disk type='block' device='disk' model='virtio-non-transitional'>
> +      <driver name='qemu' type='raw'/>
> +      <source dev='/dev/HostVG/QEMUGuest1'/>
> +      <target dev='vda' bus='virtio'/>
> +    </disk>
> +    <controller type='usb' index='0' model='none'/>

s/index='0' //

[...]
> +++ b/tests/qemuxml2argvdata/virtio-transitional.xml
> @@ -0,0 +1,17 @@
> +<domain type='qemu'>
> +  <name>QEMUGuest1</name>
> +  <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
> +  <memory unit='KiB'>219136</memory>
> +  <os>
> +    <type arch='x86_64' machine='q35'>hvm</type>
> +  </os>
> +  <devices>
> +    <disk type='block' device='disk' model='virtio-transitional'>
> +      <driver name='qemu' type='raw'/>
> +      <source dev='/dev/HostVG/QEMUGuest1'/>
> +      <target dev='vda' bus='virtio'/>
> +    </disk>
> +    <controller type='usb' index='0' model='none'/>

Here too.


Reviewed-by: Andrea Bolognani <abologna at redhat.com>

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list