render / rpms / libvirt

Forked from rpms/libvirt 9 months ago
Clone
c401cc
From c18594a43b583f497baaf07b4d540bf7cab8634f Mon Sep 17 00:00:00 2001
c401cc
Message-Id: <c18594a43b583f497baaf07b4d540bf7cab8634f.1389183248.git.jdenemar@redhat.com>
c401cc
From: Laine Stump <laine@laine.org>
c401cc
Date: Thu, 2 Jan 2014 03:12:52 -0700
c401cc
Subject: [PATCH] domain: don't try to interpret <driver> as virtio config for
c401cc
 hostdev interfaces
c401cc
c401cc
This resolves:
c401cc
c401cc
  https://bugzilla.redhat.com/show_bug.cgi?id=1046337
c401cc
c401cc
The <driver> name attribute of an interface is interpreted in two
c401cc
different ways depending on the <interface> type - if the interface is
c401cc
type='hostdev', then the driver name describes which backend to use
c401cc
for the hostdev device assignment (vfio or kvm), but if the interface
c401cc
is any emulated type *and* the model type is "virtio", then the driver
c401cc
name can be "vhost" or "qemu", telling which backend qemu should use
c401cc
to communicate with the emulated device.
c401cc
c401cc
The problem comes when someone has defined a an interface like this
c401cc
(which is accepted by the parser as long as no <driver name='xxx'/> is
c401cc
specified):
c401cc
c401cc
    <interface type='hostdev'>
c401cc
       ...
c401cc
       <model type='virtio'/>
c401cc
       ...
c401cc
    </interface>
c401cc
c401cc
As libvirt storing this definition in the domain's status, the driver
c401cc
name is automatically filled in with the backend that was
c401cc
automatically decided by libvirt, so it stores this in the status:
c401cc
c401cc
    <interface type='hostdev'>
c401cc
       ...
c401cc
       <driver name='vfio'/>
c401cc
       ...
c401cc
       <model type='virtio'/>
c401cc
       ...
c401cc
    </interface>
c401cc
c401cc
This isn't noticed until the next time libvirtd is restarted - as it
c401cc
is reading the status of all domains, it encounters the above
c401cc
interface definition, logs an error:
c401cc
c401cc
  internal error: Unknown interface <driver name='vfio'> has been specified
c401cc
c401cc
and fails to reload the domain status, so the domain is marked as
c401cc
inactive.
c401cc
c401cc
The solution is to stop the parser from interpreting <driver>
c401cc
attributes as if the device was an emulated virtio device, when it is
c401cc
actually a hostdev.
c401cc
c401cc
(Although the bug has existed since vfio support was added, it has
c401cc
just recently become more apparent because libvirt previously didn't
c401cc
automatically set the driver name for hostdev interfaces in the domain
c401cc
status to vfio/kvm as it does since commit f094aa, first appearing in
c401cc
v1.1.4.)
c401cc
c401cc
(cherry picked from commit 3337a98a5ee41ee1d5de796abcb378eacb9bded0)
c401cc
c401cc
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
c401cc
---
c401cc
 src/conf/domain_conf.c | 3 ++-
c401cc
 1 file changed, 2 insertions(+), 1 deletion(-)
c401cc
c401cc
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
c401cc
index 656fa93..d4161a5 100644
c401cc
--- a/src/conf/domain_conf.c
c401cc
+++ b/src/conf/domain_conf.c
c401cc
@@ -6607,7 +6607,8 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt,
c401cc
         model = NULL;
c401cc
     }
c401cc
 
c401cc
-    if (def->model && STREQ(def->model, "virtio")) {
c401cc
+    if (def->type != VIR_DOMAIN_NET_TYPE_HOSTDEV &&
c401cc
+        STREQ_NULLABLE(def->model, "virtio")) {
c401cc
         if (backend != NULL) {
c401cc
             int name;
c401cc
             if ((name = virDomainNetBackendTypeFromString(backend)) < 0 ||
c401cc
-- 
c401cc
1.8.5.2
c401cc