[libvirt] [PATCH] domain: don't try to interpret <driver> as virtio config for hostdev interfaces

Eric Blake eblake at redhat.com
Tue Dec 24 17:13:05 UTC 2013


On 12/24/2013 09:26 AM, Laine Stump wrote:
> This resolves:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1046337
> 
> The <driver> type attribute of an interface is interpreted in two
> different ways depending on the <interface> type - if the interface is
> type='hostdev', then the driver name describes which backend to use
> for the hostdev device assignment (vfio or kvm), but if the interface
> is any emulated type *and* the model type is "virtio", then the driver
> name can be "vhost" or "qemu", telling which backend qemu should use
> to communicate with the emulated device.
> 

> 
> This isn't noticed until the next time libvirtd is restarted - as it
> is reading the status of all domains, it encounters the above
> interface definition, logs an error:
> 
>   internal error: Unknown interface <driver name='vfio'> has been specified
> 
> and fails to reload the domain status, so the domain is marked as
> inactive.

Always annoying when that happens.

> 
> The solution is to stop the parser from interpreting <driver>
> attributes as if the device was an emulated virtio device, when it is
> actually a hostdev.
> 
> (Although the bug has existed since vfio support was added, it has
> just recently become more apparent because libvirt previously didn't
> automatically set the driver name for hostdev interfaces in the domain
> status to vfio/kvm as it does since commit f094aa, first appearing in
> v1.1.4.)

Thanks for the analysis - in spite of taking a long time to write, a
long commit message does make it easier to validate that the patch is right.

ACK.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131224/4349bc24/attachment-0001.sig>


More information about the libvir-list mailing list