vsphere creates machines with multiple clashing nics
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Christian Muirhead |
Bug Description
Reported on Juju discourse https:/
The controller machine (and subsequent deploys) creates machines with 2 nic:s with the same MAC addresses and hence the same IP-addresses. This obviously causes networking issues and I’m not sure what part juju has in this atm.
Subsequent “juju deploy foobar” equally creates machines with this very same problem (even reusing the MAC-address from the juju controller host).
Help
I’m trying to figure out if the problem is in vsphere or in juju. Since this worked fine on a previous controller (unfortunately torn down so I don’t know the version).
I bootstrap with the following:
juju bootstrap vmware01 iuba-vmware --config config.yaml --bootstrap-
The content of config.yaml:
primary-network: VLAN_802
datastore: H280-VIC847-0001
allow-model-access: true
The content of the model-default.yaml:
datastore: H280-VIC847-0001
primary-network: VLAN_802
apt-mirror: https:/
The resulting controller machine ends up with 2 nic:s as the picture belowScreenshot
The MAC-addresses are the same on those NIC:s and hence also given the same IP-addresses.
This never happened before. The version of juju is: 2.6.8-bionic-amd64
snap list
juju 2.6.8 8873 stable canonical✓ classic
Anyone that has a clue on whats going wrong here?
Things I’ve tried with no avail:
Messing around with external-network and primary-network with no avail.
Messing around with templates.
Changed in juju: | |
status: | In Progress → Incomplete |
Changed in juju: | |
milestone: | 2.6.9 → 2.6.10 |
Changed in juju: | |
milestone: | 2.6.10 → 2.6.11 |
Changed in juju: | |
status: | Incomplete → Fix Released |
Changed in juju: | |
milestone: | 2.6.11 → 2.6.9 |
I have down-graded to 2.6.6-bionic-amd64 and still have 2 nics generated instead of the requested one, but they have different mac addresses so they do function. These were deploying to non-vsan volumes.