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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list