[libvirt] Possible bug in OpenVZ guest interface name assignment
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. Could somebody confirm all this? If so, I could open a new ticket in bugzilla and submit a patch. Best, Alvaro Polo Valdenebro Product Development & Innovation / Telefónica Digital C/ Don Ramón de la Cruz 82-84 Madrid 28006 (+34) 609 087 054 apv@tid.es ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
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).
participants (2)
-
ALVARO POLO VALDENEBRO -
Laine Stump