Zitat von Albert Braden <ozzzo@yahoo.com>:

> This is what I see in the log:
>
> 2024-12-27T19:06:10.482Z|01793|bridge|WARN|could not open network 
> device qvo0430a2f7-cd (No such device)
>
> When I do "openstack port list --long" I get ID, Name, MAC, IPs, 
> Status, Security Groups, Owner and Tags, but I don't see anything 
> that matches qvo0430a2f7-cd. How do I translate qvo0430a2f7-cd to a 
> port UUID?    On Tuesday, January 14, 2025 at 01:30:43 AM EST, 
> Eugen Block <eblock@nde.ag> wrote:
>
>  Basically, it's a port, so you could try to show|delete|modify it:
>
> openstack port list | grep {whatever}
> openstack port show|delete|set {PORT_UUID}
>
> Zitat von Albert Braden <ozzzo@yahoo.com>:
>
>> I apologize for the vague question. This particular interface is 
>> orphaned. It looks like the VM may have been deleted during a 
>> maintenance and the interface failed to delete. The symptom is that 
>> every time I delete a VM, on the hypervisor with the orphaned 
>> interface, it takes substantially longer than other hypervisors, so 
>> I'm guessing that the orphaned interface is confusing Neutron.
>>
>> Is is possible to perform operations on an interface, without 
>> reference to a VM? I'd like to delete this orphaned interface, 
>> hopefully without manually editing the DB.
>>       On Monday, January 13, 2025 at 01:54:19 PM EST, Eugen Block 
>> <eblock@nde.ag> wrote:
>>
>>   You can see the current interfaces with:
>>
>> nova interface-list {UUID}
>>
>> Zitat von Albert Braden <ozzzo@yahoo.com>:
>>
>>> I poked around in the Neutron documentation, but I can't find the 
>>> commands interfaces. I looked at the Neutron API but the only 
>>> "interface" commands there relate to routers. Is there an Openstack 
>>> tool that will let me view or delete interfaces?
>>>       On Friday, January 10, 2025 at 02:30:02 AM EST, Eugen Block 
>>> <eblock@nde.ag> wrote:
>>>
>>>   Hi,
>>>
>>> the short answer is, I don't know. It really depends on what exactly 
>>> the issue is here. It requires some investigation to be able to tell 
>>> if any openstack tools can help, e. g. neutron related commands, or if 
>>> you need to tackle this from ovs directly, or if it's a database 
>>> inconsistency or maybe something else entirely.
>>> For example, what I referred to was an interface that wasn't attached 
>>> to an instance anymore, and the port didn't exist anymore, but the 
>>> database had not been properly updated. I didn't see any other way 
>>> than to manually update the DB. But you might be facing something 
>>> different here, maybe someone else has experienced the same as you, 
>>> but since nobody else responded yet, you'll have to dig on your own.
>>>
>>> Zitat von Albert Braden <ozzzo@yahoo.com>:
>>>
>>>> Hi Eugen,
>>>>
>>>> Thanks for your email. I'm not aware of a VM that corresponds to the 
>>>> stuck interface. Every VM deletion on the affected hypervisor is 
>>>> delayed; this has been happening for a few weeks now. Looking at the 
>>>> logs, it appears that an interface is created when a VM is created, 
>>>> and deleted with that VM. I'm guessing that the interface may have 
>>>> become stuck when a customer deleted a VM during a maintenance, and 
>>>> the interface failed to delete. Is it possible to delete an 
>>>> interface without editing the database?
>>>>       On Thursday, January 9, 2025 at 07:54:46 AM EST, Eugen Block 
>>>> <eblock@nde.ag> wrote:
>>>>
>>>>   Hi,
>>>>
>>>> maybe some more history and details could help understand what might 
>>>> be the issue here.
>>>> So you have VMs with one or more interfaces that you try to delete. Do 
>>>> you see those interfaces in 'nova interface-list {UUID}'? And while 
>>>> deleting the VMs, ovs takes a long time becaus it can't find those 
>>>> devices, correct?
>>>>
>>>> This reminds me of our reinstallation a few months ago as well 
>>>> (importing the previous DB dump). After migrating from openSUSE to 
>>>> Ubuntu (Victoria), we upgraded to Wallaby. In the post-upgrade steps 
>>>> the 'nova-manage db online_data_migrations' failed because of a few 
>>>> instances with a weird port state. A user attached a new interface 
>>>> according to the event list, but we don't see a detach in the logs 
>>>> although the instances had only one remaining NIC (as before). We had 
>>>> to dig really deep, including manipulating the DB (mark that interface 
>>>> as deleted).
>>>> We didn't try to delete those instances in that weird state, so I'm 
>>>> not sure if we could have ended up in the same situation as you. But 
>>>> maybe you have a similar thing going on with those undeleted 
>>>> interfaces in the DB that OVS tries to delete? Hard to tell...
>>>>
>>>> Regards,
>>>> Eugen
>>>>
>>>> Zitat von Albert Braden <ozzzo@yahoo.com>:
>>>>
>>>>> I didn't see a response to this email. Trying again with a 
>>>>> better subject:
>>>>>       On Friday, January 3, 2025 at 10:20:56 AM EST, Albert Braden 
>>>>> <ozzzo@yahoo.com> wrote:
>>>>>
>>>>>  
>>>>> One of our busiest clusters was rebuilt on Wallaby a few months ago (kolla-ansible) and deletions are taking a long time for VMs on some hypervisors. When I look at the ovs-vswitchd.log on the slow hypervisors I see lots of errors that apparently refer to a missing VM interface:
>>>>>
>>>>> 2024-12-27T19:06:10.482Z|01793|bridge|WARN|could not open network device qvo0430a2f7-cd (No such device)
>>>>>
>>>>> For most network devices I see "added" and "deleted" lines in the log. This one has an "added" line but no "deleted". I tried restarting the neutron_openvswitch_agent and openvswitch_vswitchd containers but that didn't make a difference. How can I get OVS to stop choking on this missing interface?