cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: Behavior with regard to private NICs (KVM)
Date Mon, 29 Oct 2012 13:30:55 GMT
I'll take a look and address the concerns later today. #2 I can see
immediately as its an if-else, but I don't see how the change affected #1
from the previous behavior, just looking on my phone.
On Oct 29, 2012 3:21 AM, "Dave Cahill" <> wrote:

> Hi all,
> From, we can see that the CloudStack agent
> fails to start if there is no "private" NIC name set.
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/
>  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?
> Thanks,
> Dave Cahill.
> [1]

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