Re: [Users] simple networking? [SOLVED] mostly
On Mon, Dec 16, 2013 at 06:01:51PM -0500, Antoni Segura Puimedon wrote:
----- Original Message -----
> From: "Moti Asayag" <masayag(a)redhat.com>
> To: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
> Cc: users(a)ovirt.org, "Juan Pablo Lorier" <jplorier(a)gmail.com>
> Sent: Monday, December 16, 2013 8:43:24 PM
> Subject: Re: [Users] simple networking? [SOLVED] mostly
>
> By looking at the output of 'getCapabilities' i noticed vdsm
> didn't report any value for 'lastClientIface':
'lastClientIface': ''
>
> It seems like the first 'getCapabilities' which the engine relies
> on to report the nic for configuring the management network on top
> of is missing.
>
> Toni, any idea in which case it might not be reported ?
Sure, this is fixed now (or at least the behavior was changed). The thing
is that this Caps reports the management_ip as 0.0.0.0, which leads me to
believe that this is probably an all in one setup. The code for getting
lastClientIface used to check for which device had assigned the management_ip,
which doesn't exist in this case.
management_ip 0.0.0.0 means very little: only that Vdsm has kept its
default of listening on all interfaces. I do not see how it is related.
If we were to use the current code, that tries to route a packet, it would
behave differently. However, it would still leave us out of luck as the device
that would be reported to the engine would be, if this is indeed
an allinone, the loopback device.
I am confused about this reasoning. The vdsm.log.26.xz shows 10 calls to
getCabilities, all from 192.168.128.79. Two of them (the first included)
reports that odd lastClient = '0.0.0.0'. Both happen to be the first
call after Vdsm has started up.
It smells like a race (or a more consistent fault) in how we set
self.server.lastClient = self.client_address[0]
I'd apreciate a bug opened on that, for a closer scrutiny.
Dan.