Re: [libvirt] [PATCH] qemu: set macvtap physdevs online when macvtap is set online

On 04/15/2015 02:59 PM, John Ferlan wrote: This is some defensive programming to protect against physdev being NULL (which *should* be impossible for type='direct', but not verifiably so without a much larger context). The idea is that I never call virNetDevGetOnline at all unless physdev != NULL. So if physdev was NULL, I want isOnline to be set to true so I won't try to "virNetDevSetOnline(NULL, true);". If I was more trustful of the code (much of which was probably written or reviewed by me) I wouldn't need this. Yes and no. On one hand, it's nice to put everything back exactly how we found it. On the other, when an interface is being used for either hostdev passthrough or macvtap passthrough, it can't be used for anything else, so we know that at the time we started using it it was unused, and immediately after we're finished it will be unused, and ifup'ing an interface that isn't in use only leads to grief (for example, I believe certain versions of NetworkManager like to notice things like this and start up dhclient on the interface). Also there is the hostdev passthrough usage to consider - in that case, we detach the device from the host net driver, then reattach it; when we reattach it always ends up offline, so this behavior in macvtap passthrough is no different. I considered modifying the replace/restoreconfig functions to save and restore the online status of the interface so that all types of networking use would terminate with the device in exactly the same state in which it was found. Unfortunately, when doing hostdev passthrough the replace/restoreconfig functions are both called while the VF is detached from the host driver, and although there is an IFLA_VF_LINK_STATE in the IFLA_VF_INFO stuff, it is only implemented for a small subset of drivers (not including the most common ones - igbvf and ixgbvf) and it can only be used to *set* the state, but not to get it. So that's out. Another thing that I discovered while looking into this is that the other macvtap modes simply don't work at all on a VF; the VF driver prevents promiscuous mode (supposedly for security reasons), but the other macvtap modes don't work properly without it. And a VF isn't really very useful as a host netdev either - you don't get any extra bandwidth, for example, because it's using the same physical port as the PF. So if you want to use macvtap bridge or private mode, you need to just use the PF (I still haven't figured out vepa/802.1Qbg). If there was something the host was using the interface for before we started using it, it's going to have to be setup again when we're done, so it will require some other intervention anyway, and the device could be put online at that time. How about this - I'll make a separate patch that modifies the replace/restore config functions to save and restore the online status of the VF only for the cases that we can also access it directly as a netdev. Then it will be preserved properly for the cases when we are able. I want to make it a separate patch so that it can be cleanly reverted if we later decide that is actually a *bad* thing to do, though.