<br><br><div class="gmail_quote">On Thu, Feb 2, 2012 at 6:08 PM, Laine Stump <span dir="ltr"><<a href="mailto:laine@laine.org" target="_blank">laine@laine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On 02/02/2012 09:30 AM, Ansis Atteka wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Libvirt has a function virNetDevBridgeRemovePort() which can<br>
remove port from the Linux Bridge, but it seems that no one calls it.<br>
<br>
Wanted to confirm if port removal happens automatically for Linux<br>
Bridges if VM goes down?<br>
</blockquote>
<br></div>
I didn't write that code, and have never traced through to verify this, but here's my understanding:<br>
<br>
* the tap device is created non-persistent and attached to its bridge (in virNetDevTapCreateInBridgePort<u></u>())<br>
<br>
* the fd of the open tap device is passed to qemu, and qemu uses it for network communication.<br>
<br>
* when it's time to detach the device or destroy the guest, libvirt just sends a monitor command to qemu, which ends up closing the tap device. Because the tap device was non-persistent, that automatically leads to 1) removal of the tap device from the bridge, and 2) deletion of the tap device itself.<br>

</blockquote><div>Yeah, the problem is that OVS does not do 1) when tap device gets destroyed.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If a non-persistent tap device that is attached to an OVS is closed, does OVS not notice this and automatically detach it? You may want to experiment with that; possibly nothing is needed.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
(it would be much better if not, because otherwise there will need to be special care taken to prevent dangling tap devices (or dangling references to deleted tap devices))<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The difference between OVS and<br>
Linux Bridge is that OVS will need a hook that removes all ports on<br>
VM shutdown event (and maybe also for some other events?).<br>
</blockquote>
<br></div>
Not just when a guest is shutdown, but also if a network device is detached from a running domain.<br>
<br>
If it's necessary to explicitly detach the tap from the OVS, whatever hook is added in to do that can hopefully just as well be identical for a Linux bridge (i.e., the only OVS-specific code should be in the lowest level function that does that bridge detach).<br>


<br>
Another point - since a shutdown initiated by the guest would likely end up destroying the tap device, we can't just add in a hook to detach it from the bridge - too early and the guest won't be done with it yet, too late and it will already not exist. I'm thinking that instead we may need to create the tap as persistent, then explicitly detach it from the bridge and delete it after the domain is finished with it.</blockquote>

<div>It wouldn't be too late. It's ok If actual tap device is not alive anymore.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

If that is needed, I think it should be done in a separate patch that is a prerequisite to the OVS patch. That way the two things can be tested independent of each other.<br>
<br>
As soon as I get out the patch I'm working on now, I'll take a quick look at this and see if I can point your more in the right direction for this prerequisite patch. In the meantime, it would be useful if you could do the experiment I mentioned above (i.e. do nothing and see if it explodes), and modify virNetDevBridgeRemovePort for your patch to do the right thing in the case of the bridge device being an OVS.</blockquote>
<div>If by experiment you meant "Whether OVS automatically detaches tap device from OVS bridge when tap device gets closed?" then I can confirm that in contrast to Linux Bridge it does not do that. I will look into possibilities to remove ports on "detach-interface" and "VM shutdown" events.</div>

</div>