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(a)redhat.com>
--
Andrea Bolognani / Red Hat / Virtualization