MAAS

esxi deployment do not get networking and host configuration post deployment

Bug #2023786 reported by Jeff Hillman
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Expired
Undecided
Unassigned

Bug Description

focal
maas 3.1.1-10918-g.9cbd96fd2

When deploying an ESXi image to an enlisted and ready server, the installation finishes from a VMware installer perspective, however when the machine comes up, it doesn't get the actual IP configuration that was sent via curtin, nor does it get a hostname assigned.

This snippit from the logs shows it was trying to be sent to the ESXi host.

```
cloud-init[1620]: start: cmd-install/stage-network: configuring network
cloud-init[1620]: start: cmd-install/stage-network/builtin: running 'curtin net-meta custom'
cloud-init[1620]: start: cmd-install/stage-network/builtin/cmd-net-meta: curtin command net-meta
cloud-init[1620]: net-meta mode is 'custom'. devices=[]
cloud-init[1620]: writing to file /tmp/tmpu8_1hzto/state/network_config with network config: network:
cloud-init[1620]: config:
cloud-init[1620]: - id: enp1s0
cloud-init[1620]: mac_address: 52:54:00:18:13:c4
cloud-init[1620]: mtu: 1500
cloud-init[1620]: name: enp1s0
cloud-init[1620]: subnets:
cloud-init[1620]: - address: 192.168.100.12/24
cloud-init[1620]: dns_nameservers:
cloud-init[1620]: - 192.168.100.10
cloud-init[1620]: dns_search:
cloud-init[1620]: - maas
cloud-init[1620]: gateway: 192.168.100.1
cloud-init[1620]: type: static
cloud-init[1620]: type: physical
cloud-init[1620]: - address:
cloud-init[1620]: - 192.168.100.10
cloud-init[1620]: search:
cloud-init[1620]: - maas
cloud-init[1620]: type: nameserver
cloud-init[1620]: version: 1
cloud-init[1620]: finish: cmd-install/stage-network/builtin/cmd-net-meta: SUCCESS: curtin command net-meta
cloud-init[1620]: finish: cmd-install/stage-network/builtin: SUCCESS: running 'curtin net-meta custom'
cloud-init[1620]: builtin took 0.250 seconds
cloud-init[1620]: stage_network took 0.250 seconds
cloud-init[1620]: finish: cmd-install/stage-network: SUCCESS: configuring network

```

When the machine boots up, it instead gets a DHCP address from MAAS's dynamic pool. And ultimately it goes to a Failed Deployment state, yet still stays up and is usage from an ESXi perspective.

I have tested this with legacy BIOS, UEFI and Secure Boot, all exhibit the same behavior.

Test with ESXi 7 and 8.

Tags: cpe-onsite
Revision history for this message
Alexsander de Souza (alexsander-souza) wrote :

can you access this host and get us the contents of `/var/log/maas.log` ?

Changed in maas:
status: New → Incomplete
Revision history for this message
Jeff Hillman (jhillman) wrote :

Relayed from the customer, as they cannot directly update the bug.

Attaching maas logs

Revision history for this message
Jeff Hillman (jhillman) wrote :

Relayed from the customer, as they cannot directly update the bug.

Attaching maas logs

Revision history for this message
Alexsander de Souza (alexsander-souza) wrote :

sorry for not being more clear. I meant the `/var/log/maas.log` file in the ESXi host. This file is created during the first boot and has the output of the scripts that configure the host (e.g. /altbootbank/maas/netplan-esxi)

Changed in maas:
status: Incomplete → New
status: New → Incomplete
Revision history for this message
Jeff Hillman (jhillman) wrote :

relaying from the customer:

There’s no maas.log

[root@10-127-50-210:~] find / -name maas.log

[root@10-127-50-210:~] find / -name "*maas*"

/vmfs/volumes/445da873-f64f4865-158e-5471f757ef3a/maas

/vmfs/volumes/445da873-f64f4865-158e-5471f757ef3a/maas/maas-md-get

[root@10-127-50-210:~] ls /vmfs/volumes/445da873-f64f4865-158e-5471f757ef3a/maas

PyYAML-5.4.1.dist-info maas-md-get

_yaml netplan-esxi

bin oauthlib

certifi oauthlib-3.1.0.dist-info

certifi-2023.5.7.dist-info requests

chardet requests-2.25.1.dist-info

chardet-4.0.0.dist-info storage-esxi

curtin.cfg urllib3

idna urllib3-1.26.16.dist-info

idna-2.10.dist-info vcenter

ipaddr-2.2.0.dist-info vendor-data-esxi

ipaddr.py yaml

[root@10-127-50-210:~] ls /vmfs/volumes/445da873-f64f4865-158e-5471f757ef3a/maas

/maas-md-get

/vmfs/volumes/445da873-f64f4865-158e-5471f757ef3a/maas/maas-md-get

Revision history for this message
Alexsander de Souza (alexsander-souza) wrote :

two things are strange here:

1) /var/log/maas.log is always created in the first boot
2) /altbootbank/maas (or /vmfs/../maas) is removed after the first boot

the fact that none of these things happened is unexpected, it's like the ´%firstboot` script in the kickstart file didn't run.

did the client do any customization in this image?

Changed in maas:
status: Incomplete → New
status: New → Incomplete
Revision history for this message
Wayne (wgoodric) wrote :

My latest failed attempt was using the vanilla image from VMware

Revision history for this message
Björn Tillenius (bjornt) wrote :

Can you share the exact steps and configuration you use when you build the image using packer?

Changed in maas:
status: Incomplete → New
status: New → Incomplete
Revision history for this message
Jeff Hillman (jhillman) wrote :

Comments from the customer affected, they cannot update the bug directly very easily.

The command I used to build the image:

make ISO=~/BNYM-vmware-esxi-7u3k-21313628-Dell-Rackmount-Mar2023

The command to import to MaaS

maas admin boot-resources create name=esxi/7.3 title="ESXi 7.3.0 BNY custom" architecture=amd64/generic filetype='ddgz' content@=vmware-esxi.dd.gz

The customizations in that ISO are Dell drivers. But I can duplicate the issue with the VMware vanilla image.

One thing that should be noted in that bug, is that I can successfully deploy with secure boot disabled

Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

Is this issue reproducible after the fix for https://bugs.launchpad.net/maas/+bug/2022084? It's not clear whether there's something wrong with the custom image, or secure boot behaviour.

Alberto Donato (ack)
Changed in maas:
status: Incomplete → New
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for MAAS because there has been no activity for 60 days.]

Changed in maas:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.