knife-vsphere icon indicating copy to clipboard operation
knife-vsphere copied to clipboard

in `ipv4_address': undefined method `origin' for nil:NilClass (NoMethodError)

Open bby-bishopclark opened this issue 7 years ago • 5 comments

Versions:

  • Version of knife-vsphere: 2.0.0
  • Version of chef: 1.3.220

Platform Details

  • Version of vSphere: Chrome Version 60.0.3112.78
  • Version of ESXi: VMware ESXi, 5.5.0, 4722766

Scenario:

A simple-ish VM Clone op

Please paste the command and output (run with -VV). Don't forget to X out any passwords or sensitive information:

See the gist below.

Expected Result:

clone, bootstrap, etc; like normal

Actual Result:

gist here

bby-bishopclark avatar Sep 21 '17 21:09 bby-bishopclark

Hi there, sorry for the delay in responding, and thanks for gisting the full debug output.

I think the culprit is Found address fe80::250:56ff:fe99:f85e. The agent is returning the IPv6 link local address that you probably can't connect to.

Try it with the --bootstrap-ipv4 flag, and it'll continue to wait until it gets a v4 address.

swalberg avatar Sep 22 '17 12:09 swalberg

Actually, that's on line 5 -- no fooling! But you're totally correct that it should get dead air if it was on ipv6 (I love how c7 will do that, without there being an actual network there; haven't run the 'disable ipv6' challenge on this template yet though)

bby-bishopclark avatar Sep 22 '17 15:09 bby-bishopclark

Oh I'm sorry, I missed that! I will have to look into this a bit more.

swalberg avatar Sep 22 '17 15:09 swalberg

I think I tripped over the reason.

Our config around lists of variables, like ifcfg-eth0, often restate variables. Since those files are sourced, we'll restate parameters like bootproto= and NM_controlled;

DEVICE=eth0
BOOTPROTO=dhcp
PEERDNS=no
:
#moar
:

BOOTPROTO=static
NETMASK=255.255.254.0
IPADDR=10.53.8.46
GATEWAY=10.53.9.254
DNS1=10.21.9.210

The second bit overlays the first when the file is sourced in, so it's valid for us.

But now I think some piece is reading the file line by line, seeing the first BOOTPROTO, and quitting there. It decides that dhcp is what we're doing, but gets no address in our dry environment. Then, when it raises the nic, with its customized info, the nic either sets its old IP or ends up with none .. which is why/how only ipv6 is lit up.

Anyway, removing the first bootproto line allowed a single invocation to work. I'll close this if i can get a few more as proof. It would strongly indicate that the OS and customization are not reading the same file the same way, and those of us exploiting OS behaviour to be lazy with layers could shoot ourselve sin the foot.

bby-bishopclark avatar Sep 22 '17 19:09 bby-bishopclark

Interesting... We suggest you nuke those files in your template because they can cause problems, though this is the first time I've seen this particular problem happen because of it.

swalberg avatar Sep 22 '17 19:09 swalberg