knife-vsphere
knife-vsphere copied to clipboard
in `ipv4_address': undefined method `origin' for nil:NilClass (NoMethodError)
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:
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.
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)
Oh I'm sorry, I missed that! I will have to look into this a bit more.
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.
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.