[libvirt] Possible bug in OpenVZ guest interface name assignment

[Laine Stump]

On 05/23/2013 06:25 AM, ALVARO POLO VALDENEBRO wrote:
> Hi,
>
> I think I've found a possible bug in the way OpenVZ is assigning the guest interface names when network is bridged. It's manifested at least in 1.0.5 version and master branch.
>
> As we can see in openvzDomainSetNetwork() function (openvz/openvz_driver.c:822), the field data.ethernet.dev of virDomainNetDefPtr type is used as guest interface name. If not found, then it generates a new one as ethX, calculating the next X value appropriate for the target domain.
>
> That's fine for network types other than VIR_DOMAIN_NET_TYPE_BRIDGE. But with bridged networks, there is no chance to populate data.ethernet.dev from the XML descriptor. We could guest that in such circumstance the code will detect that no name is given to data.ethernet.dev, so it will generate a new one. But that's incorrect. The virDomainNetDef.data field is a union, so data.ethernet.dev and data.bridge.brname are located in the same memory offset. That makes the openvzDomainSetNetwork() function to assign the bridge name as guest interface name every time it's invoked for bridged networks.
>
> Ideally, for bridged networking openvzDomainSetNetwork() should assign a random ethX device name instead of using the bridge name.


I'm unfamiliar with the openvz driver code, but just a quick glance at
the function verifies that *something* is wrong - as you say it is
accessing/modifying things in the net->data.ethernet union when the type
isn't ETHERNET, and that should never be done.


>
> Could somebody confirm all this? If so, I could open a new ticket in bugzilla and submit a patch.


For upstream issues there is no need to open a bugzilla ticket,
especially if you're going to submit a patch to fix it.

I think the best way to proceed would be for you to just write the patch
and send it. You changes will help to point out exactly what the problem
is, and we'll have something concrete to use as a basis for discussion
(and will very likely push it in short order).