[libvirt] [PATCH 0/4] Support mac and port profile for <interface type='hostdev'>

[Roopa Prabhu]

On 3/2/12 12:54 PM, "Laine Stump" <laine at laine.org> wrote:

> On 03/02/2012 03:03 PM, Roopa Prabhu wrote:
>> On 3/2/12 11:04 AM, "Laine Stump" <laine at laine.org> wrote:
>>> On 03/01/2012 04:02 AM, Roopa Prabhu wrote:
>>>> This patch series is based on laines patches to support <interface
>>>> type='hostdev'>.
>>>> https://www.redhat.com/archives/libvir-list/2012-February/msg01126.html
>>>> 
>>>> It support to set mac and port profile on an interface of type hostdev.
>>>> * If virtualport is specified, the existing virtual port functions are
>>>> called to set mac, vlan and port profile.
>>> I'm unable to test that part, as I don't have any 802.1QbX capable
>>> switches (and it sounds like the design is problematic anyway.)
>>> 
>> The design is still fine for 802.1Qbh.
> 
> 
> Yes, my apologies for misinterpreting all the exchanges.
> 
> 
No problem atall. 

>> I have tested it. 802.1Qbh does not
>> need a macvtap device. For 802.1Qbg in v2 (was planning on pushing it the
>> next hr),
> 
> 
> I'll try to review it as quickly as possible.
> 
> 
>>  I have put a check for 802.1Qbg and hostdevs and fail as suggested
>> by stefan.
> 
> 
> I'm quickly learning that I understood much less about 802.1QbX (and in
> particular, how it's been implemented) than I thought! (Fortunately, as
> a result of all this, I think I now understand it a bit better).
> 
> 

And I am understanding 802.1Qbg a bit better now :)

>>>> * If virtualport is not specified and device is a sriov virtual function,
>>>> - mac is set using IFLA_VF_MAC
>>> Success!! I tried this for VFs that have a netdev driver attached, and
>>> VFs that don't, and it behaved properly in both cases - when the guest
>>> is started, the MAC address is set properly for the guest to use, and
>>> when the guest is stopped, the MAC address of that VF is restored to its
>>> original value (implying that your code to save the old MAC address
>>> works properly).
>>> 
>>> 
>> Nice. Thanks for trying it out.
>> 
>>>> * If virtualport is not specified and device is a non-sriov virtual
>>>> function,
>>>> - mac is set using existing SIOCGIFHWADDR (This requires that the
>>>>         netdev be present on the host before starting the VM)
>>> This one has a problem, at least with my non-sriov hardware (which
>>> happens to be the onboard NetXtreme device of a Thinkstation, using the
>>> tg3 driver) it appears the MAC address gets reset to its original
>>> setting at some point after libvirt changes it. To help understand what
>>> happens - assume the device's original MAC address is o:o:o:o:o:o, and
>>> my xml looks like this:
>>> 
>>>   <interface type='hostdev' managed='yes'>
>>>     <mac address='n:n:n:n:n:n'/>
>>>     ...
>>>   </interface>
>>> 
>>> When the guest boots up, ifconfig shows there is an interface with mac
>>> address o:o:o:o:o:o.
>>> 
>>> Additionally, if I manually change the mac address to p:p:p:p:p:p on the
>>> host before starting the guest, when the guest boots, ifconfig shows the
>>> mac address as... o:o:o:o:o:o. So, whether or not libvirt is
>>> successfully setting the mac address, it's getting reset (probably by
>>> the card's firmware).
>> Yes this I kind of expected. It depends on the driver. I thought there are
>> some drivers that remember the mac address set by SIOCGIFHWADDR. But my
>> assumption was totally based on the fact that we wanted to add support for
>> all devices. Having the code there just means we try to set the device mac.
>> It takes effect only if the hw supports it.
> 
> If there was just a way to determine that at runtime, but it seems that
> by the time the MAC address has been reset, we are no longer able to
> call the ioctl to check the address :-(
> 
> 
>>> So perhaps this is another case of wanting to do something that just
>>> isn't possible, and the way out is to simply generate an error on domain
>>> startup if the netdev being passed through isn't a VF?
>>> 
>>> 
>> We can do this too. Only support it for sriov vf's.
> 
> Yes, if it's going to silently do the wrong thing, maybe we should leave
> the SIOCGIFHWADDR code in there for reference, but also add a failure
> condition if the card isn't SRIOV.

Ok. Heres what I will do (If I understand you correctly):
- I will call the mac/portprofile set functions for sriov devices only.
- Throw an error for non-sriov devices
- Keep the mac set code for non-sriov devices around for reference

> 
> (I guess this means my effort to make sure USB ethernets were also
> supported was kind of pointless, since they're sure to have the same
> problems :-P Mostly I only included that support to promote code sharing
> and consistency, though, so I'm not really disappointed.)
> 

:) 

Thanks Laine.