cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cahill <>
Subject Behavior with regard to private NICs (KVM)
Date Mon, 29 Oct 2012 09:20:39 GMT
Hi all,

>From, we can see that the CloudStack agent
fails to start if there is no "private" NIC name set.


 698         getPifs();
 699         if (_pifs.get("private") == null) {
 700             s_logger.debug("Failed to get private nic name");
 701             throw new ConfigurationException("Failed to get private
nic name");
 702         }

In other words, the agent fails to start if the entry for "private" in the
HashMap returned by getPifs() is null.

A recent commit [1] seems to have changed the behavior of getPifs() so that
this happens more often. The new code has two behaviors which seem strange
to me:

1. The value of the "private" entry is effectively set to the interface of
the *last* bridge in the list returned by "brctl show".
2. A single bridge can only be used to set either the "public" or the
"private" value of the HashMap.

This means that the getPifs() HashMap entry for "private" is null (causing
the agent to fail to start) in two situations which seem normal:

1. A bridge with no interfaces defined exists on the system.
For example, libvirt creates a bridge called virbr0 by default, which has
no interfaces. When getPifs() sees this entry, it counts it as null. If
this entry is the last one in the list, "private" is set to null.

2. The private and public bridge are the same.
>From my reading of the previous code, if _guestBridgeName and
_publicBridgeName were set to the same value (only one bridge defined), the
entries in _pifs for "public" and "private" would be the same, and the
agent would start correctly. However, the new code loops through the
bridges, setting them as the value of *either* public or private (or
neither), so if there is only one bridge available, the "private" entry in
pifs will be null.

I'm just coming up to speed with the code base, so there may easily be a
good reason for this behavior change. Does anyone have an explanation?

Dave Cahill.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message