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).