[libvirt] RFC: Detaching interface from guest fails with improper error message if no mac given in xml

Michal Privoznik mprivozn at redhat.com
Fri Sep 29 09:05:07 UTC 2017


On 09/29/2017 09:15 AM, Madhu Pavan wrote:
> This RFC is regarding https://bugzilla.redhat.com/show_bug.cgi?id=1497054
> 
> Let's say we have a network interface
>     <interface type='network'>
>       <mac address='52:54:00:fe:10:57'/>
>       <source network='vfnetwork'/>
>       <model type='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x01' slot='0x01'
> function='0x0'/>
>     </interface>
> 
> and we are trying to detach the above interface with the following
> xml(vfpool.xml):
>     <interface type='network'>
>       <source network='vfnetwork'/>
>       <model type='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x01' slot='0x01'
> function='0x0'/>
>     </interface>
> Detaching the interface returns error:
> # virsh detach-device vffuest vfpool.xml
> error: Failed to detach device from vfpool.xml
> error: operation failed: no device matching mac address
> 52:54:00:54:f6:61 found
> 
> Here the mac address is auto-generated as we haven't given in the
> vfpool.xml.
> And virDomainNetFindIdx will try to match the auto-generated mac address
> with
> the domain xml. It fails as there will be no match and the error message
> says
> "no device matching mac address 52:54:00:54:f6:61 found".
> 
> Here in this scenario I see two possible improvements.
> 1. As virDomainNetFindIdx search according to mac address and guest side
>    PCI address (if specified), we can search for PCI address and avoid
>    mac address search if mac is not given in the xml. As the PCI address
>    is unique we don't compromise in performance.

Well, since I had discussion about (hot) unplug API recently, I still
remember that it's documented that users are required to pass the full
device XML and not just a portion of it.

> 2. Improve error message by saying mac address is missing in the device
> xml.

But this is an actual bug. We can do better here.

Michal




More information about the libvir-list mailing list