Packer: 第2代Hyper-V VM引导速度太快，无法启动boot_command

日志输出：
==> hyperv-iso：正在创建构建目录...
==> hyperv-iso：检索ISO
hyperv-iso：就地使用文件：file：/// C：/Automation/ISO/Newest2016/windows2016.ISO
==> hyperv-iso：在端口8068上启动HTTP服务器
==> hyperv-iso：根据需要创建开关“ internal_switch” ...
==> hyperv-iso：开关'internal_switch'已经存在。 清理时不会删除...
==> hyperv-iso：创建虚拟机...
==> hyperv-iso：启用集成服务...
==> hyperv-iso：将引导驱动器设置为os dvd驱动器C：/Automation/ISO/Newest2016/windows2016.ISO ...
==> hyperv-iso：安装OS DVD驱动器C：/Automation/ISO/Newest2016/windows2016.ISO ...
==> hyperv-iso：跳过安装Integration Services安装磁盘...
==> hyperv-iso：正在挂载辅助DVD映像...
==> hyperv-iso：正在安装辅助DVD驱动器。/windows/2016/answer.iso...
==> hyperv-iso：配置VLAN ...
==> hyperv-iso：启动虚拟机...
==> hyperv-iso：尝试与vmconnect连接...
==> hyperv-iso：HyperV计算机的主机IP：192.168.10.103
==> hyperv-iso：输入启动命令...
==> hyperv-iso：等待WinRM可用...

当Packer进入“正在键入启动命令...”部分时，虚拟机已经超过了“按任意键从cd或dvd启动”的提示。

我试图以无头模式启动，但是VM仍然启动得太快。 除了建立一个不提示我按键开始安装的ISO之外，我不太确定是否有解决方案。 在同一台Windows 10计算机上构建第1代VM的过程中，我已经取得了很多成功，但是我在这里没有看到提示。 以下是我正在使用的模板。

{
“建筑商”：[
{
“ boot_wait”：“ 0s”，
“ boot_command”：[“ a一种一种一种一种一种一种” ]，
“ configuration_version”：“ 9.0”，
“ vm_name”：“ windows2016”，
“ type”：“ hyperv-iso”，
“ disk_size”：76800，
“ floppy_files”：[]，
“ secondary_iso_images”：[
“ ./windows/2016/answer.iso”
]，
“无头”：假，
“ http_directory”：“ ./windows/common/http/”，
“ guest_additions_mode”：“禁用”，
“ iso_url”：“ ../ISO/Newest2016/windows2016.ISO”，
“ iso_checksum_type”：“无”，
“ iso_checksum”：“ e3779d4b1574bf711b063fe457b3ba63”，
“ communicator”：“ winrm”，
“ winrm_username”：“无业”，
“ winrm_password”：“流浪汉”，
“ winrm_timeout”：“ 4h”，
“ shutdown_command”：“关闭/ s / t 10 / f / dp：4：2 / c \”打包程序关闭\“”，
“ ram_size”：2048，
“ cpu”：1
“代”：2
“ switch_name”：“ internal_switch”，
“ enable_secure_boot”：是
}
]，
“供应商”：[
{
“ type”：“ powershell”，
“ elevated_user”：“无业”，
“ elevated_pa​​ssword”：“流浪”，
“脚本”：[
“ ./windows/common/cleanup.ps1”
]
}
]，
“后处理器”：[
{
“ type”：“无业游民”，
“ keep_input_artifact”：否，
“输出”：“ {{.Provider}} _ windows-2016.box”
}
]
}

@marcinbojko我知道您已经对第二代Windows VM做了很多工作-您对这里的解决方法有任何见解吗？ 我不认为Packer可以在这里做任何事情，因为Gen 2虚拟机是如此之快地启动了整个启动过程。

@SwampDragons-有趣的是-有很多不同的Hyper-V堆栈（不同的裸机和版本），不同的DVD / ISO测试我可以说一件事：这是不可预测的；）
不幸的是，我发现的唯一解决方法是使启动循环与：

      "boot_command": [
        "a<enter><wait>a<enter><wait>a<enter><wait>a<enter>"
      ],

@SwampDragons我建议使用“启动延迟”功能，因为

功能的名称在这里：

 get-vm -Name ito-el6-n1.spcph.local|select name,automaticstartdelay

Name                   AutomaticStartDelay
----                   -------------------
ito-el6-n1.spcph.local                   0

Startup_delay是一个很好的提示！ 我将其添加到hyper-v文档中。

大家好，非常感谢您在此提出的建议。 不幸的是，AutomaticStartDelay设置在这里无济于事，因为它不会减慢启动虚拟机时的启动过程。

当重新启动运行许多VM的hyper-v主机或整个hyper-v群集时，AutomaticStartDelay的真正作用是防止引导风暴。

例：
VM1在host1上运行
VM1的AutomaticStartDelay设置为60秒
主机1重新启动
VM1最初在重新启动之前在host1上运行，因此当hyper-v服务启动时，VM1将自动再次启动
Hyper-V等待60秒，然后再启动/启动VM1
60秒后，VM1开机并以最快的速度运行引导过程。

我将看一下这里建议的boot_command调整。 我当前的boot_command字符串当前为： "boot_command": [ "a<wait>a<wait>a<wait>a<wait>a<wait>a<wait>a" ],

尽管我看不到VM会多次重启，但它似乎对VM没有任何影响。 尽管我猜想它实际上可以工作。 我将抓取一些屏幕截图，以使您更好地了解最终发生的情况。

嗯，我尝试了以下设置，但VM似乎根本没有从打包程序中获取任何输入：
"boot_wait": "5s",
"boot_command": ["<leftCtrlOn><leftAltOn><endOn><leftCtrlOff><leftAltOff><endOff><wait>a<enter>"],

@KimRechnagel-我对您的问题的最初理解是
我不记得有这些问题，即使是在具有SSD存储的超高速快速主机上也是如此。
您可以开始收集数据吗？ Packer版本，您正在使用的终端（cmd，powershell，conemu）。
我还要说-让我们尝试更改ISO，因为我记得一些最新版本（虽然我正在使用合作伙伴频道）在boot_command方面存在问题-您可以下载并检查常规的Windows 2016 Evaluation ISO吗？
最后但并非最不重要的一点是，您可以尝试我的模板吗？
https://github.com/marcinbojko/hv-packer

@SwampDragons-它不是那么好，因为它必须在VM创建过程中由

@marcinbojko是的，

我并不想太粗鲁，但是AutomaticStartDelay与此问题无关，因为此设置的工作方式与我上面所述完全相同。 通过将AutomaticStartDelay设置为10秒，然后启动VM，在计算机上进行了本地测试。 在启动请求发送到VM之后，它不会延迟任何时间，它只是告诉主机等待X秒，以便在主机（例如）启动时将启动请求发送到VM。 已重新启动。

我将使用另一个ISO进行测试，并且还将根据您的建议收集有关我的系统，版本等的数据。

感谢您的反馈意见。

@KimRechnagel-不用担心，我们对您的问题的首次了解将建议使用startdelay-我们已经排除了此问题。

嗯，“解决方案”可能很简单，例如让打包程序在发送Start-VM cmdlet之前连接到VM。

我只是手动“测试”了它，然后发生的是我连接到VM并看到了黑色控制台。 当我按下启动按钮时，仍然需要vmconnect大约3-4秒才能真正显示启动屏幕。 在超时之前，我看到“按任意键从CD或DVD引导...”大约1秒钟，然后尝试进行PXE引导。

我猜问题可能只是vmconnect.exe太慢而无法连接。 好吧，我也会研究一下。

@KimRechnagel-如果您为此特定的打包程序VM切换到增强会话（在vmconnect中），将会发生什么？

@marcinbojko增强的会话已启用。 我禁用了它，但不幸的是它没有改变任何东西。

我确实进行了其他测试，但是使用DHCP / PXE等带来了很多其他挑战，但是如果我将启动顺序更改为：
硬盘
网络适​​配器
DVD驱动器（我安装ISO）
DVD驱动器（带有autounattend.xml的answer.iso等）

然后，VM等待PXE超时，并且vmconnect有足够的时间连接到VM。 问题是在PXE超时结束时以及“按任意键启动....”超时时，我只有一个小窗口发送启动命令。 此外，如果我的网络上有DHCP / BOOTP，则启动过程将更加复杂。

有关hyper-v上的boot_commands的问题； 文档指出，我可以在“ <LeftCtrl> ”中添加“ On”，以便打包程序按住键，这将允许我发送Ctrl，Alt，End（重新启动）。 但它似乎不起作用。 可能是因为未在Hyper-v上以与VirtualBox，VMWare等相同的方式实现扫描代码？

我尝试过
"boot_command": ["<leftCtrlOn><leftAltOn><endOn><leftCtrlOff><leftAltOff><endOff><wait>a<enter>"],
但是它什么也没做。 好吧，也许我的问题是boot_command根本没有发送：-)

创建Gen1 VM时，我从未见过“按任意键启动...”，因此我实际上不知道boot_command是否可以在我的设置中使用。

仍在等待eval ISO下载。

我当前的设置：

这距安装有多远？ 它刚开始吗？
我的设置中没有看到bootmgfw.efi。

这很有趣-我的包装员刚刚经历了第三批WU。
据我所知（在2016/2019）Gen2机器应该具有此文件。

我测试了从github存储库链接的模板。 我使用的是从VLSC网站下载的ISO。 同样的问题。 下载完成后，我将在大约20分钟内使用eval ISO再次进行测试。

我的模板设置：

看来您的Hyper-V主机是物理主机，还是至少在Server 2016上运行？ 我正在用Windows 10最新版本的笔记本电脑进行测试，这可能在构建Gen 2机器时有所不同。

真正。 我不是Windows专家，但是我将尝试使用w10。

确定评估ISO已完成下载。 除了ISO，我什么都没做，我使用了您的模板...它可以工作。 这很奇怪...好像eval ISO在“按任意键启动”提示下等待的时间大约长1-2秒，这意味着打包程序有时间连接和发送boot_command。

是的，这就是我在您提到的话题中注意到的。 切换到其他ISO（合作伙伴渠道）破坏了我的部署流程。 怪微软？

它不适用于我自己修改的模板。 我现在测试了两次，boot_command似乎没有发送。 我将一次调整设置一次，直到找出触发此设置的原因。

哇，这很奇怪。 我还通过更改"iso_url": ".\\iso\\Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO",来“破坏”您的模板

至： "iso_url": "../ISO/Newest2016/Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO",

改回来，它又能正常工作

好了，现在您的模板再次失败了。 它连续连续三次失败。 这很奇怪。 在工作与否之间有一个非常非常好的平衡。
我会继续测试。

我刚刚用w10 1803进行了测试（没有1809，因为它无法升级）。
使用合作伙伴ISO，我什至无法启动，“按下按键显示1秒钟”就消失了。
@SwampDragons-很抱歉，这与上一期有关

使用debug and headless：false：

==> hyperv-iso：配置VLAN ...
==> hyperv-iso：启动虚拟机...
==> hyperv-iso：尝试与vmconnect连接...
==> hyperv-iso：HyperV计算机的主机IP：169.254.2.24
==> hyperv-iso：输入启动命令...
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05发送char'a'，代码'1e9e'，shift false
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05发送char'a'，代码'1e9e'，shift false
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05特殊代码'Press'''找到，替换为：＆{[1c] [9c]}
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05发送char'a'，代码'1e9e'，shift false
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05特殊代码'Press'''找到，替换为：＆{[1c] [9c]}
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05发送char'a'，代码'1e9e'，shift false
2019/02/06 11:30:05 packer.exe：2019/02/06 11:30:05特殊代码'Press'''找到，替换为：＆{[1c] [9c]}
2019/02/06 11:30:11 packer.exe：2019/02/06 11:30:11 [DEBUG]在连接步骤中无法获取地址：无IP地址。
2019/02/06 11:30:11 packer.exe：2019/02/06 11:30:11等待WinRM，超时：8h0m0s

在vmconnect显示之前，它已经消失了很长时间，而且我只能获得PXE引导菜单。

我用您的模板marcinbojko做了一些测试，这是结果以及我在测试过程中所做的更改。 我想得出的结论是：不要使用超快速存储在Hyper-V上构建Gen 2 VM。

尝试＃

1. 失败的
2. 失败的
3. 失败的
4. 更改：将vmcomput.exe优先级设置为低-工作一次
5. 失败的
6. 失败的
7. 更改：将vmcompute.exe亲和力设置为CPU0-只能工作一次
8. 失败的
9. 失败的
10. 失败的
11. 失败的
12. 更改：使用以下命令开始对ISO进行五个顺序的校验和检查：fciv。\ Windows_Server_2016_Datacenter_EVAL_zh-cn_14393_refresh.ISO-仅工作一次
13. 工作了
14. 更改：进行了无限循环校验和检查.cmd文件-失败
15. 失败的
16. 工作了
17. 失败的
18. 更改：开始了四个并行的无限校验和检查（SSD差-CPU耗尽）-虚拟机花了很多时间启动-取消了一个校验和并且虚拟机启动了-包装程序boot_command超时-失败
19. 更改：三个并行的无限校验和检查-可行，在安装开始前不久，我确实看到了启动管理器
20. 更改：两个并行的无限校验和检查-可行
21. 工作了
22. 工作了
23. 工作了
24. 工作了
25. 工作了
26. 工作了
27. 测试了我的原始模板-仍在运行两个无限校验和检查-工作
28. 工作了
29. 工作了

已通过EVAL ISO（以https：// link的形式）进行了测试-在SSD上可运行100％的时间-iso的启动管理器会等待LONGER。

除尝试27-29以外，所有上述测试均通过ISO评估进行。
评估ISO： https :

嗯...现在它的表现更加有趣（两个isos）。
我可以看到PXE菜单10-15秒。 Packer仍在等待WINRM（通过afterboot菜单击键）。
然后出乎意料的是，当PXE失败时，VM重新启动到ISO DVD并继续部署（成功）

您是否更改了启动顺序？ 听起来您的NIC高于Install ISO。

不。 DVD仍然优先。（ISO），硬盘驱动器，网络适配器，辅助ISO。
但是我已经启用了PackerDebug。

与packer_log = 0相同。 大约需要1分钟才能使PXE超时，然后继续。

我想知道是否还有其他人有这个问题。 上周，我开始使用packer，因为我将为hyper-v和不久的VMWare使用packer构建多个基本模板。

我的下一步是使Ansible与我们的hyper-v群集进行交互，并使用打包程序模板构建VM。 我目前正在本地进行所有测试，但最终会将所有内容移至专用服务器。 我猜想当我转移到安装了hyper-v的虚拟服务器时，那么我可能不会再遇到此问题了。

当我的构建失败时，我会看到大约一分钟：

然后，它-一直停留在这里，直到我停止VM：

W10 1803在这里，但我可以将其测试到hv2019集群中。

1809年在这里。 我将构建专用的打包器服务器，然后开始在该服务器上进行测试。

是的，我们将比较笔记。

@marcinbojko非常感谢您对这个问题的帮助和反馈，我非常感谢。 我猜想这个“问题”是打包程序开发人员无法控制的，因为这并不是打包程序编码问题。

不客气我已经开始在2019年年底进行测试，我们会知道更多。

@ KimRechnagel ， @ SwampDragons-我想确认一下：在W2019（me）和w10（Kim）打包机上，如果在相当快速的存储上运行，则无法从DVD引导。 就我而言，它是完全在SSD上构建的S2D。 我从问题“交换机名称中的空格”中使用了打包程序1.3.5，因为我的交换机的名称中确实包含空格。

这非常令人沮丧，但我认为Packer对此无能为力。 谷歌搜索表明，对于不使用Packer的人来说，也存在此“在第2代vms上Windows在启动屏幕中移动得太快”的问题。 我将其标记为上游错误并关闭，但是如果有人对可靠的解决方法有任何好的建议，我希望将它们添加到文档中。

感谢您的所有帮助@marcinbojko。

@SwampDragons很抱歉回答已解决的问题-我想尝试将-AutomaticStartDelay传递给New-VM或Set-Vm。 因此顺序如下：运行vmconnect和WAIT以启动VM。
问题是我对Golang毫无头绪。 如果不是太多，您能指出一段构建或设置“ new-vm”或“ set-vm”部分的代码吗？

啊，对不起； 没意识到您正在考虑添加此选项。 用于编译hyperv驱动程序的powershell脚本位于此处，特别是new-vm代码位于此处

new-vm代码使用golang模板生成最小的powershell脚本，并允许我们解决将大量参数传递到Powershell调用中的问题。

@marcinbojko我在具有本地硬盘的独立物理Dell Poweredge 815 Hyper-V 2012 R2主机上测试了您的模板。 有趣的是，我看到的行为与您相同。 VM启动，我看到“按任意键”提示大约3-4秒（Packer似乎已在此处连接），然后VM进入PXE引导，在60秒后返回“按任意键”超时，然后然后开始安装。

2012/2016，Windows 10最高可达1803。W101809/2019 =打包程序无法使用。

@marcinbojko只是一个更新。 我在hyper-v 2016群集上构建了嵌套的hyper-v主机。 我使用了来自VLSC网站的原始1809 ISO以及评估ISO，到目前为止，封隔器连接速度太慢没有任何问题。 在我当前的设置中，似乎vmconnect.exe的连接速度更快，因此缺少boot_command并不是问题。

有趣。 DNS问题？

我不这么认为，因为如果vmconnect依赖DNS查找本地VM，这是没有意义的。

我想您的嵌套HV是独立的，没有AD主机？

是的，它是一个独立的hyper-v主机。 它的唯一目的是构建打包程序模板，该模板将在基础架构中其他位置的Ansible服务器上使用。 打包程序hyper-v主机是AD的成员，并使用AD DNS服务器。 Hyper-V主机还是专用于打包程序模板的DHCP服务器。

我试图以无头模式启动，但是VM仍然启动得太快。

我_希望_我有这个错误。 我所有的Hyper-V映像都需要48个小时才能构建。 如果任何构建卡在“等待ssh访问阶段”，有时可能会更长。

关于解决方案，我有几个想法可以尝试（我自己显然没有硬件可以这样做）...即，尝试将PXE（又称为网络启动选项）添加到启动顺序中。 那可能会买您需要的秒数。 您可以修改这部分packer代码以包括网络启动选项。 只需更新packer正在使用的powershell命令。

更可靠的故障可能是在没有ISO的情况下引导计算机（或者，如果需要确保已配置DVD驱动器，则使用不可引导的虚拟ISO）...，然后等待新的来宾到达UEFI错误屏幕（如图所示）下面）。 从那里您可以安装实际的安装ISO，并有足够的延迟，让packer通过首先触发重新启动（即press any key ）到新安装的ISO来启动引导命令/安装过程。 。

如果后一种想法可行（又名，如果您通过手动安装/交换ISO对其进行测试），那么我们知道了潜在的解决方案，重点可能转移到让packer使用此策略。

我已经遇到同样的问题，并希望这似乎是为我工作的细节的东西。

首先我的环境：

• 主机：Windows 10版本1809
• 硬件：PCIe SSD
• 打包机v1.3.5
• Powershell 5.1
• 操作系统：Windows Server 2019 Eval（Microsoft网站）
• 生成2，经过验证的DVD作为第一个引导选项
• 不无头。 vmconnect运行

问题：
正如其他人提到的那样，当虚拟机首次启动时，它会在打包程序连接之前通过启动选项运行，从而使您陷入以下屏幕：

注意：此屏幕实际上是冻结的。 我花了一段时间才意识到这一点，但是如果您已经做到了这一点，那么打包程序将无法再发送启动命令。 我一直尝试发送ctrl + alt + del / ctrl + shift + alt + del尝试重新启动计算机，但没有任何反应。

解

对于我来说，感觉很像黑客的解决方案是等待冻结的启动屏幕超时。 （大约60 s）。 之后，此错误屏幕将启动：

好的新功能是，一旦进入错误屏幕，打包程序就可以再次开始发送启动命令，因此从这里只需按Tab键，然后按Enter键即可重新启动。

这是代码：

            "boot_wait": "70s",
            "boot_command": [
                "<tab><wait><enter><wait>",
                "a<wait>a<wait>a<wait>a<wait>a<wait>a<wait>"
            ],

为什么不使用efisys_noprompt.bin文件创建映像，然后完全跳过此“按任意键”操作。 适用于所有虚拟机管理程序。 不要忘记获取新的哈希（Get-FileHash）

如果有人愿意对其进行测试，我们将为PR提供一个潜在的解决方案：

https://circleci.com/gh/hashicorp/packer/9097#artifacts/containers/0

@SwampDragons-这对我

@SwampDragons谢谢，这也对我们
您知道1.4.4何时发布吗？

下周，大概是星期二。 :)

@SwampDragons ，感谢您的辛勤工作！ Packer 1.4.4已发布，可以在https://packer.io/downloads.html页面上找到。
会在https://github.com/hashicorp/packer/releases发布
docker镜像会在hub.docker.com上更新吗？

嗯，我会修复该链接。 但是，1.4.4存在一个严重的HyperV错误，直到发布后我们才发现它-您可能应该使用已经链接到那里的夜间版本。

哦，我想我在做什么。 我正在修正这个破碎的意图，它以某种方式滑落了。

@marcinbojko我的错是没有在测试中发现它。 它已经固定在master分支上，所以不用担心。

我将锁定此问题，因为它已关闭_30天_⏳。 这可以帮助我们的维护人员发现并集中精力解决当前存在的问题。

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