5642似乎正在报告相同的问题。 但是，该报告中出现了使用Hyper-V构建CoreOS的问题。 如上所述，我认为此问题不是特定于任何一个构建器或OS的。

核心问题似乎是Packer假定实例在重新启动后始终会收到相同的IP地址/租约。

目前，Packer首先进入一个循环，以确定它应该尝试连接的IP地址。 显然，所使用的逻辑取决于构建器。 Packer确定IP后，它将进入另一个尝试建立连接的循环。 如果在Packer处于第二个循环时（如在计算机重新引导时）IP地址发生更改，则连接尝试最终将超时并失败。

为了解决这个问题，需要合并两个循环，例如Packer应该不断尝试确定已分配给实例的IP地址，然后尝试在同一循环中进行连接。

当前的代码结构方式使此问题难以解决，因为连接逻辑/循环已被所有构建者使用的通用帮助程序分解。

FWIW，我在Packer 1.5.1和Photon OS 3 Rev 2中遇到相同的问题。 看来，虚拟机为了通过kickstart进行启动而获得了租约，但是IP会在客户机重新启动并准备好Packer接管时改变。 Packer只是在等待它必须首先看到的IP —用于通过HTTP访问kickstart配置的IP。

我刚刚通过将open-vm-tools软件包添加到kickstart文件中的软件包列表中来使Photon OS 3正常工作：

{
  "hostname": "haproxy-lb",
  "password": {
    "crypted": false,
    "text": "photon"
  },
  "disk": "/dev/sda",
  "install_linux_esx": true,
  "packages": [
    "minimal",
    "linux",
    "initramfs"
  ],
  "additional_packages": [
    "ca-certificates",
    "curl",
    "gzip",
    "haproxy",
    "jq",
    "lsof",
    "lvm2",
    "ntp",
    "openssh-server",
    "open-vm-tools",
    "sed",
    "shadow",
    "sudo",
    "tar",
    "vim"
  ],
  "postinstall": [
    "#!/bin/sh",
    "useradd -U --groups wheel photon && echo 'photon:photon' | chpasswd",
    "useradd --system --home-dir=/var/lib/haproxy --user-group haproxy",
    "mkdir -p /home/photon",
    "chown -R photon:photon /home/photon",
    "mkdir -p /var/lib/haproxy",
    "chown -R haproxy:haproxy /var/lib/haproxy",
    "systemctl enable sshd",
    "systemctl disable haproxy",
    "echo 'photon ALL=(ALL) NOPASSWD: ALL' >/etc/sudoers.d/photon",
    "chmod 440 /etc/sudoers.d/photon",
    "tdnf clean all"
  ]
}

编辑：实际上，即使将open-vm-tools添加到预置中，我仍然仍然遇到此问题。

@akutz谢谢你！ 将open-vm-tools添加到Debian preseed文件（相当于Debian的kickstart）也对我有用。

d-i pkgsel/include string open-vm-tools [...space separated list of additional packages to install into the target system]

我还没看得太深，但是很明显，这可以使交互/魔术发生，以确保实例在重新启动后保持相同的IP地址-也许在/ etc / vmware-tools / scripts / vmware / network中？

尽管对于此处记录的给定OS /平台组合，这是可行的解决方法，但由于IP搜寻和连接逻辑的当前构建方式，我希望这是一个Packer用户仍会发现的错误。

Packer需要能够处理IP地址在重新启动/ DHCP地址更新期间发生更改的情况。 这里记录的那种解决方法可能并不总是可用。

@akutz不幸的是，我现在发现它只对我

@akutz不幸的是，我现在发现它只对我

嗨@DanHam ，

现在，我已经多次构建了映像，没有任何问题。

根据Packer的体系结构和我们的通信器当前的工作方式，这可能不是一件容易的更改，但是我同意Packer在理想情况下将支持IP地址更改的情况。

我想知道，为什么这是vmware-iso构建器上的体系结构的问题，当使用esxi时，它也能正常工作。 我在使用dnsmasq作为dhcp。 因此，不可能查看文件。 相反，打包程序必须使用open-vm-tools或esxi api（我想）。
因此，为什么不经常寻找租约文件中的变化，而仅将最后一个条目作为有效IP。

我曾尝试在本文中使用open-vm-tools构建debian 10，但仍然无法正常工作。
我尝试使用1.5.1版（官方版本）和vmware工作站14.1.7 build-12989993，并尝试使用15.5.1版-15018445版本

我发现了一个临时的工作人员，或者说是一个黑客。
我创建了一个子网掩码为255.255.255.248的新接口
并从2 ips选择dhcp范围。
现在，dhcp只能为虚拟机提供2 ips。
第一个IP将在安装过程中给出。
第一次重新引导后将提供第二个IP。

/ etc / vmware / networking中网络文件的配置如下：

VERSION=1,0
answer VNET_10_DHCP yes
answer VNET_10_DHCP_CFG_HASH 8D292DB10AA5381B846E260EADE516BB459E6D65
answer VNET_10_HOSTONLY_NETMASK 255.255.255.248
answer VNET_10_HOSTONLY_SUBNET 172.16.230.0
answer VNET_10_NAT yes
answer VNET_10_NAT_PARAM_UDP_TIMEOUT 30
answer VNET_10_VIRTUAL_ADAPTER yes
answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH B70C98E2E155E3E7349FFCA26CE5694851E233FB
answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
answer VNET_1_HOSTONLY_SUBNET 172.16.65.0
answer VNET_1_VIRTUAL_ADAPTER yes
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH 39B4FEBF27D7259C57192A984AA39AD7DDA1FAC4
answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
answer VNET_8_HOSTONLY_SUBNET 172.16.229.0
answer VNET_8_NAT yes
answer VNET_8_VIRTUAL_ADAPTER yes
answer VNL_DEFAULT_BRIDGE_VNET -1
add_bridge_mapping ens192 -1
add_bridge_mapping br1 0

/et/vmware/vmnet10/dhcpd/dhcpd.conf中的配置文件如下：

# Configuration file for ISC 2.0 vmnet-dhcpd operating on vmnet10.
#
# This file was automatically generated by the VMware configuration program.
# See Instructions below if you want to modify it.
#
# We set domain-name-servers to make some DHCP clients happy
# (dhclient as configured in SuSE, TurboLinux, etc.).
# We also supply a domain name to make pump (Red Hat 6.x) happy.
#


###### VMNET DHCP Configuration. Start of "DO NOT MODIFY SECTION" #####
# Modification Instructions: This section of the configuration file contains
# information generated by the configuration program. Do not modify this
# section.
# You are free to modify everything else. Also, this section must start
# on a new line
# This file will get backed up with a different name in the same directory
# if this section is edited and you try to configure DHCP again.

# Written at: 01/10/2020 11:01:36
allow unknown-clients;
default-lease-time 1800;                # default is 30 minutes
max-lease-time 7200;                    # default is 2 hours

subnet 172.16.230.0 netmask 255.255.255.248 {
        range 172.16.230.4 172.16.230.6;
        option broadcast-address 172.16.230.7;
        option domain-name-servers 172.16.230.2;
        option domain-name localdomain;
        default-lease-time 1800;                # default is 30 minutes
        max-lease-time 7200;                    # default is 2 hours
        option netbios-name-servers 172.16.230.2;
        option routers 172.16.230.2;
}
host vmnet10 {
        hardware ethernet 00:50:56:C0:00:0A;
        fixed-address 172.16.230.1;
        option domain-name-servers 0.0.0.0;
        option domain-name "";
        option routers 0.0.0.0;
}
####### VMNET DHCP Configuration. End of "DO NOT MODIFY SECTION" #######

/etc/vmware/vmnet10/nat/nat.conf中的配置文件如下：

# VMware NAT configuration file
# Manual editing of this file is not recommended. Using UI is preferred.

[host]

# NAT gateway address
ip = 172.16.230.2
netmask = 255.255.255.248

# VMnet device if not specified on command line
device = /dev/vmnet10

# Allow PORT/EPRT FTP commands (they need incoming TCP stream ...)
activeFTP = 1

# Allows the source to have any OUI.  Turn this on if you change the OUI
# in the MAC address of your virtual machines.
allowAnyOUI = 1

# Controls if (TCP) connections should be reset when the adapter they are
# bound to goes down
resetConnectionOnLinkDown = 1

# Controls if (TCP) connection should be reset when guest packet's destination
# is NAT's IP address
resetConnectionOnDestLocalHost = 1

# Controls if enable nat ipv6
natIp6Enable = 0

# Controls if enable nat ipv6
natIp6Prefix = fd15:4ba5:5a2b:100a::/64

[tcp]

# Value of timeout in TCP TIME_WAIT state, in seconds
timeWaitTimeout = 30

[udp]

# Timeout in seconds. Dynamically-created UDP mappings will purged if
# idle for this duration of time 0 = no timeout, default = 60; real
# value might be up to 100% longer
timeout = 30

[netbios]
# Timeout for NBNS queries.
nbnsTimeout = 2

# Number of retries for each NBNS query.
nbnsRetries = 3

# Timeout for NBDS queries.
nbdsTimeout = 3

[incomingtcp]

# Use these with care - anyone can enter into your VM through these...
# The format and example are as follows:
#<external port number> = <VM's IP address>:<VM's port number>
#8080 = 172.16.3.128:80

[incomingudp]

# UDP port forwarding example
#6000 = 172.16.3.0:6001

我想知道，为什么这是vmware-iso构建器上的体系结构的问题，当使用esxi时，它也能正常工作。 我在使用dnsmasq作为dhcp。 因此，不可能查看文件。 相反，打包程序必须使用open-vm-tools或esxi api（我想）。
因此，为什么不经常寻找租约文件中的变化，而仅将最后一个条目作为有效IP。

我曾尝试在本文中使用open-vm-tools构建debian 10，但仍然无法正常工作。
我尝试使用1.5.1版（官方版本）和vmware工作站14.1.7 build-12989993，并尝试使用15.5.1版-15018445版本

我还发现，在Photon上，重新引导后的第一次尝试过了一段时间后，它失败了。 最后，我通过在两次尝试之间将其杀死来使它起作用：

$ sudo ps alx | grep vagrant
    0  2316     1   0  20  0 558440636    384 -      Ss     ??    0:00.11 /opt/vagrant-vmware-desktop/bin/vagrant-vmware-utility api -port=9922

请记住，我不是在运行Vagrant。 但是我敢打赌，Packer正在利用Vagrant的某些东西。

基于此更改日志https://github.com/hashicorp/vagrant-plugin-changelog/blob/master/vagrant-vmware-utility-changelog.md ，确实出现了vagrant-vmware-utility用于DHCP中一些能力。

也许与https://github.com/hashicorp/vagrant/issues/9915有关

嗨@DanHam ，

我刚刚注意到我的vagrant-vmware-utility是1.0.5而1.0.7 （下载）是最新版本。 我将对其进行升级，看看是否有帮助。

看起来，打包器使用WinRM Communicator不断查询新的IP。
现在，我发现一种“适当的”解决方法比前面提到的上一种更好。 （其他骇客解决方法无法切实发挥作用）
我现在通过在/etc/vmware/<vmnet>/dhcpd/目录中创建dhcpd.conf和dhcpd.leases文件来在桥接网络接口上伪造dhcp服务器。
我通过解析打包器输出来询问网络上的dhcp（dnsmasq dhcp，使用自定义rest api + curl）来填充租约文件，其中ip属于硬件地址。 除此之外，我将dhcp配置为每个硬件地址仅分配一个IP，并忽略客户端ID。
另外，我在dhcp上实现了一个脚本，该脚本在每次创建新租约时都会运行。 然后，脚本在/ etc / ethers文件中创建一个条目以创建静态分配。

VMWare工作站15正在使用ISC DHCP版本2，因此，未实现忽略客户端ID的选项。 这是许多标准dhcp服务器的默认选项，如果有，则首选客户端ID而不是硬件ID。 甚至来自isc的非常新的kea dhcp都将其用作默认选项。 这就是为什么我想出了这种“解决方法”。 似乎，与脚本结合使用来忽略客户端标识符的选项是一种适当的解决方法。

我为遇到相同问题的人创建了要点：
https://gist.github.com/llxp/006ad6c7aa5d81e7283631e76fd1ed71

你好。

我们遇到了同样的问题，个人认为这样的方法可行：为VirtualBox构建虚拟机，以后可以轻松将其导入到VMware。 我暂时没有发现这种方法的局限性，但至少可以在Debian 10中使用。

对我来说，将open-vm-tools添加到该文件中不起作用。

我找到了一种解决方法，可以添加到预置文件中：

d-i preseed/late_command string \ sed -i 's/^#*\(send dhcp-client-identifier\).*$/\1 = hardware;/' /target/etc/dhcp/dhclient.conf

设置dhcp-client-identifier选项，以便使用MAC地址。 这是Debian 10之前版本的默认设置（请参阅https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906894）。

@ jan-z不错的解决方法！ 这也对我有用。

请问您在哪里找到了将客户端标识符设置为= hardware的文档？ 也许我看起来不够努力，但似乎无法在dhclient文档中的任何地方找到它。

由ifupdown到dhclient的调用被硬编码到ifup二进制文件中。 Debian错误906894的修复程序添加了“ -i”标志。 如您所知，该标志导致DUID被发送到DHCP服务器，这是我们所看到的问题的根本原因。

下一版本的ifupdown应该允许用户配置对dhclient的调用是否包含'-i'标志/发送DUID。 请参阅Debian错误923640和此处的修复

@DanHam我找不到该设置的任何文档。 我从这里得到的： https :

@ jan-z好的。 我看到了...

我进行了更深入的研究。 很难找到它，但是在dhcp-options（5）手册页的SETTING OPTION VALUES USING EXPRESSIONS部分中进行了记录。 表达式的语法记录在dhcp-eval（5）手册页中。

@SwampDragons @azr @ jan-z提出的解决方法是解决此问题的正确方法-至少在此修复程序起作用之前，它已进入下一个Debian ifupdown软件包。

您是否要关闭此窗口或将其打开一段时间以便遇到相同问题的其他用户？

嗯，恕我直言，文档页面会很好，例如与该问题相匹配的简短标题/说明，以便Google轻松说明所有可能的选项。 因此，用户可以了解问题并选择所需的路径：更新/修复/其他。

编辑：超级好发现！

我在Workstation 15.5（ubuntu），打包程序1.5.4和Photon OS 3 Rev 2中遇到相同的问题。

open-vm-tools软件包的解决方法不起作用。 您知道如何在不更改vmware配置的情况下解决该问题吗？

@ jan-z解决方法也适用于我

打包器1.5.5版
vmware融合11.5.3
安装debian-10.3.0-amd64-netinst

对我来说，在Archlinux构建上也是如此。 在1.5之前，它像魅力一样工作，但现在不再可用。 更确切地说，KVM构建仍然有效，只是vmware不起作用。 重新启动后，虚拟机具有不同的IP，并且打包程序无法连接

Packer 1.5.6，Photon OS 3 Rev2和Fusion 11.5.3在此存在相同问题。

对于Photon OS，我尝试在我的kickstart后安装部分添加一行以更改dhcpclient发送uid信息的方式。 现在，结果显示两个客户端主机名已发送到DHCP服务器。

kickstart.json

{
    "hostname": "photon",
    "password":
        {
            "crypted": false,
            "text": "VMware123!"
        },
    "disk": "/dev/sda",
    "packagelist_file": "packages_appliance.json",
    "additional_packages": [
        "open-vm-tools"
    ],
    "postinstall": [
                    "#!/bin/sh",
                    "sed -i 's/PermitRootLogin no/PermitRootLogin yes/g' /etc/ssh/sshd_config",
                    "echo 'ClientIdentifier=mac' >> /etc/systemd/network/99-dhcp-en.network",
                    "systemctl restart sshd.service",
                    "tdnf clean all"
                   ]
}

/var/db/vmware/vmnet-dhcpd-vmnet8.leases

# All times in this file are in UTC (GMT), not your local timezone.   This is
# not a bug, so please don't ask about it.   There is no portable way to
# store leases in the local timezone, so please don't request this as a
# feature.   If this is inconvenient or confusing to you, we sincerely
# apologize.   Seriously, though - don't ask.
# The format of this file is documented in the dhcpd.leases(5) manual page.

lease 172.16.54.128 {
        starts 3 2020/05/06 15:11:39;
        ends 3 2020/05/06 15:41:39;
        hardware ethernet 00:0c:29:08:05:f4;
        uid ff:b6:22:0f:eb:00:02:00:00:ab:11:c4:bd:ed:7a:ca:fd:92:30;
        client-hostname "photon-installer";
}
lease 172.16.54.129 {
        starts 3 2020/05/06 15:12:23;
        ends 3 2020/05/06 15:42:23;
        hardware ethernet 00:0c:29:08:05:f4;
        uid ff:b6:22:0f:eb:00:02:00:00:ab:11:44:a7:c6:60:a7:3d:45:17;
        client-hostname "photon";
}

你好
此问题是由于“系统联网”而不是Packer
只需将以下行添加到您的/etc/systemd/network/99-dhcp-en.network文件中，就会强制dhcp客户端使用MAC，而不是“ duid”。

[DHCPv4]
ClientIdentifier=mac

cf： https ：

@pierreilki-我也尝试过:(它仍然想获取一个新的DHCP记录，从而使打包程序获得错误的ip。我还尝试设置系统的主机名以使其与安装程序的主机名匹配。 photon-installer 。

嘿，大家。 因此，我为大多数vmware构建器解析器（＃9303）编写了一些单元测试，并对dhcpd租用解析器（＃9319）进行了一些重构。 原因是因为看起来这个问题可以在builder/vmware/common/ssh.go 。

此CommHost函数向driver.GuestIP函数询问要使用的地址。 在＃9319之前， driver.GuestIP函数只是使用正则表达式来获取与硬件地址匹配的任何租约。 我们遇到的问题（或者至少是我本人）是，拥有相同硬件地址的租约不止一个。 唯一不同的是“ uid”字段，这是我们访客中的dhcpcd用来获取地址的字段。 这实际上应该是我们的“键”，但是没有很好的方法可以从来宾中导出“ uid”。 那么，为什么不抓住匹配的“一切”，然后尝试呢？

我不得不重写dhcpd租约解析器，以便首先测试起来更容易，但这样它不仅解析dhcpd租约...而且更容易提取多个匹配项，并且在任何情况下特定字段（本例中uid ）。 这样，在CommHost ，我们可以询问匹配租约的driver.GuestIP ，然后逐个检查每个租户是否匹配。

这样做可能会出现一些尚待解决的问题，但我将我的意图分解为不同的阶段，以便可以更轻松地查看其各自的修改。 PR＃9319应该与dhcpd租约解析器当前正在工作的方式完全向后兼容，并且下一个PR（我将在一分钟内开始进行处理）将最终以一种非向后兼容的方式工作更改CommHost和driver.GuestIP交互方式。

好的...我实际上感到惊讶，但PR＃9322重做driver.GuestIP以便它使用PR＃9319中新的dhcpd.leases解析器返回地址列表。 然后在CommHost ，获取地址列表并尝试每个地址，直到其中一个有效为止。 该地址然后用于ssh到访客。

现在，大概需要一两秒钟的时间，它才能知道ssh已启动，但是打包程序似乎可以识别新地址，并按照预期的那样继续进行下一个多步操作。

所以.. PR＃9322应该正确地解决这个问题，并且不要破坏您的客户机或VMware配置。

我想花一点时间感谢您在此@arizvisa上所做的所有努力！

谢谢。 任何其他奥氏体的东西。 ;）

我认为这是由于＃9303中的“关闭”关键字而意外关闭的，而该PR并没有真正解决此问题。

好的收获，谢谢。

我认为PR 9322已完全关闭了此功能。我们将在下周初发布v1.6.0。

已修复，已使用上面@DanHam链接的配置文件确认。 注：在针对v1.6.0-dev运行之前，我在本地修复了iso_checksum_type配置属性的弃用问题。

vmware-iso: output will be in this color.

==> vmware-iso: Retrieving ISO
==> vmware-iso: Trying https://cdimage.debian.org/cdimage/archive/10.2.0/amd64/iso-cd/debian-10.2.0-amd64-netinst.iso                             
==> vmware-iso: Trying https://cdimage.debian.org/cdimage/archive/10.2.0/amd64/iso-cd/debian-10.2.0-amd64-netinst.iso?checksum=sha512%3A5495c8378b829df7386b9bac5bc701f7ad8b2843d088e8636c89549519cf176100eacb90121af3934a8c5229cbe7d2fd23342eda330d56fb45fb2d91f2117fb4                             
==> vmware-iso: https://cdimage.debian.org/cdimage/archive/10.2.0/amd64/iso-cd/debian-10.2.0-amd64-netinst.iso?checksum=sha512%3A5495c8378b829df7386b9bac5bc701f7ad8b2843d088e8636c89549519cf176100eacb90121af3934a8c5229cbe7d2fd23342eda330d56fb45fb2d91f2117fb4 => /home/wilken/pkg/packer-testing-master/vmware-dhcp/packer_cache/aa283600cd4c412a3090a9399e251328ffc7ccfa.iso                                                                       
==> vmware-iso: Creating required virtual machine disks
==> vmware-iso: Building and writing VMX file
==> vmware-iso: Starting HTTP server on port 8586
==> vmware-iso: Starting virtual machine...
==> vmware-iso: Waiting 5s for boot...
==> vmware-iso: Connecting to VM via VNC (127.0.0.1:5911)
==> vmware-iso: Typing the boot command over VNC...
==> vmware-iso: Waiting for SSH to become available...
==> vmware-iso: Connected to SSH!
==> vmware-iso: Provisioning with shell script: /tmp/packer-shell527574289                                                                        
==> vmware-iso: Running local shell script: /tmp/packer-shell536900249
    vmware-iso: 4bb8ee9c-5bfc-1977-6797-ed334dcbd96c
==> vmware-iso: Gracefully halting virtual machine...
    vmware-iso: Waiting for VMware to clean up after itself...
==> vmware-iso: Deleting unnecessary VMware files...
    vmware-iso: Deleting: output-debian-10-vmware-iso/vmware.log
==> vmware-iso: Compacting all attached virtual disks...
    vmware-iso: Compacting virtual disk 1
==> vmware-iso: Cleaning VMX prior to finishing up...
    vmware-iso: Detaching ISO from CD-ROM device ide0:0...
    vmware-iso: Disabling VNC server...
==> vmware-iso: Skipping export of virtual machine (export is allowed only for ESXi)...                                                           
Build 'vmware-iso' finished.

由于将根据匹配的租约数量（而不是之前的租约）对主机列表进行线性检查...在从以前的方法中检测新地址所花费的时间上，y'all是否有明显的不同？ 这可能并不重要，但是对你们来说对我来说意义重大吗？

另外，vmware builder是唯一使用解析dhcp租约的方法来确定guest虚拟机地址的人吗？

@arizvisa就像第二个感谢您的修复！ 非常感谢！

我不得不说，我并没有真正花太多时间在构建/观看它，但是我没有注意到任何重大的延迟。 事情对我来说非常有效。

@arizvisa我上面的评论的快速更新。

我现在用最新的Packer版本构建了一些盒子。 关于Packer提取新地址所花费的时间，我有不同的结果。

有时地址会很快被拿走。 其他时候，在盒子坐在那里的情况下，几分钟后会有一个非常明显的延迟，即重启后等待Packer连接。

嗯..我想知道是否可以通过对我们解析的租赁列表进行降序排序（在PotentialGuestIP函数的末尾）来稍微提高性能，以便尝试将较新的租赁首先连接。 ..可能值得尝试的另一件事是在CommHost中并行建立连接，因为从本质上讲，其逻辑与端口扫描器相同。

无论如何，只需要考虑一些潜在的解决方案。 我可能暂时将这项实验留给维护者或其他贡献者，直到找到更多时间为止。

很有道理，感谢@arizvisa到目前为止：)

课程。 我明白了。

我将锁定此问题，因为它已关闭_30天_⏳。 这有助于我们的维护者发现并关注当前的问题。

如果您发现了一个与此相似的问题，请打开一个新问题并完成问题模板，以便我们捕获所有必要的详细信息以进行进一步调查。