cbj4074 commented 5 years ago

Versions

Vagrant: Vagrant 2.2.0
Provider: Hyper-V.
Homestead: v7.19.2

Host operating system

Windows 10 Enterprise Version 1803, build 17134.286.

Homestead.yaml

---
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: hyperv

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ~/code
      to: /home/vagrant/code

sites:
    - map: homestead.test
      to: /home/vagrant/code/public

databases:
    - homestead

Vagrant destroy & up output

https://gist.github.com/cbj4074/01317421b6ce2bf9ea8c610f76ffbecc

Expected behavior

Provisioning should succeed.

I should note that provisioning with Hyper-V succeeds when using https://app.vagrantup.com/generic/boxes/ubuntu1804/versions/1.8.40 , for example, so the issue seems to be box-specific.

Actual behavior

Provisioning fails almost immediately, when creating and registering the VM.

This seems to be related, at least in part, to the issues cited under References.

However, it seems that some/most/all of these individuals have the opposite problem (as described in the comment https://github.com/hashicorp/vagrant/issues/9317#issuecomment-437025611 ), whereby the box specifies a Hyper-V VMHost version that is greater than what the host OS supports. This seems to be a different issue, because the output on my machine reports version 8.3:

PS C:\windows\system32> Get-VMHostSupportedVersion -Default

Name                                    Version IsDefault
----                                    ------- ---------
Microsoft Windows 10 Update/Server 1803 8.3     True

The second issue cited below implies that there's a means by which to "validate the host is able to support the [Hyper-V] version". Might anyone know which value would be checked? I'd like to check it manually in the meantime.

Steps to reproduce

Attempt to provision the latest version of Homestead using the Hyper-V provider on the latest version of Windows 10.

References

cbj4074 commented 5 years ago

Upon further analysis, this looks to be some kind of regression introduced with Homestead box version 6.4.0, because version 6.3.0 works just fine with Hyper-V on the same host machine.

svpernova09 commented 5 years ago

I'm not able to reproduce this:

Vagrant 2.2.1
Windows 10 Pro 1809 OS Build 17763.134

Output of PS C:\Users\halo\PhpStormProjects\homestead> Get-VMHostSupportedVersion -Default

PS C:\Users\halo\PhpStormProjects\homestead> Get-VMHostSupportedVersion -Default

Name                                                 Version IsDefault
----                                                 ------- ---------
Microsoft Windows 10 October 2018 Update/Server 2019 9.0     True

Here's my vagrant up log:

PS C:\Users\halo\PhpStormProjects\homestead> vagrant up
Bringing machine 'homestead-7' up with 'hyperv' provider...
==> homestead-7: Verifying Hyper-V is enabled...
==> homestead-7: Verifying Hyper-V is accessible...
==> homestead-7: Importing a Hyper-V instance
    homestead-7: Creating and registering the VM...
    homestead-7: Successfully imported VM
    homestead-7: Please choose a switch to attach to your Hyper-V instance.
    homestead-7: If none of these are appropriate, please open the Hyper-V manager
    homestead-7: to create a new virtual switch.
    homestead-7:
    homestead-7: 1) packer-hyperv-iso
    homestead-7: 2) New Virtual Switch
    homestead-7: 3) Default Switch
    homestead-7:
    homestead-7: What switch would you like to use? 3
    homestead-7: Configuring the VM...
==> homestead-7: Starting the machine...
==> homestead-7: Waiting for the machine to report its IP address...
    homestead-7: Timeout: 120 seconds
    homestead-7: IP: 172.17.253.117
==> homestead-7: Waiting for machine to boot. This may take a few minutes...
    homestead-7: SSH address: 172.17.253.117:22
    homestead-7: SSH username: vagrant
    homestead-7: SSH auth method: private key
    homestead-7:
    homestead-7: Vagrant insecure key detected. Vagrant will automatically replace
    homestead-7: this with a newly generated keypair for better security.
    homestead-7:
    homestead-7: Inserting generated public key within guest...
    homestead-7: Removing insecure key from the guest if it's present...
    homestead-7: Key inserted! Disconnecting and reconnecting using new SSH key...
==> homestead-7: Machine booted and ready!

Vagrant requires administrator access for pruning SMB shares and
may request access to complete removal of stale shares.
==> homestead-7: Preparing SMB shared folders...
    homestead-7: You will be asked for the username and password to use for the SMB
    homestead-7: folders shortly. Please use the proper username/password of your
    homestead-7: account.
    homestead-7:
    homestead-7: Username: halo
    homestead-7: Password (will be hidden):

Vagrant requires administrator access to create SMB shares and
may request access to complete setup of configured shares.
==> homestead-7: Setting hostname...
==> homestead-7: Mounting SMB shared folders...
    homestead-7: C:/Users/halo/PhpStormProjects/quickstart-basic-5.3 => /home/vagrant/qs
    homestead-7: C:/Users/halo/PhpStormProjects/homestead => /vagrant
==> homestead-7: Running provisioner: file...
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: inline script
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: inline script
    homestead-7:
    homestead-7: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCntVURf8++zZjGO/JvWbo/TZgMjEqN44bFNh33Ykdf5M3ahNsFvGlw+aSWaJOLX0+3nB0lCVeV6mdXIv1ixDfiarL5leu/BN0N8LmHWhGtXi8pBGS3FiTWWGBkA2iS303Gdj3e3N8N9FdqHUtWifas8B9HvfY00P/9H2Q35AXLDvhXbUbSQMcYxYVDATd7tcoDuwdhaGdPrvmuVPps5yfPfzE9hpU2rVUnHlZ5EgwK9avS91fF0R1NAsasOzU5N3bt/T3khG5XObcHGU2Uiyi/4QbfFhVmvY+TORUoKAelFYtPrbbZfjNVYh8P04b0iudJHZ7mBRiYodj7cgJUYKFb halo@Rage
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: inline script
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: C:/Users/halo/AppData/Local/Temp/vagrant-shell20181118-11516-7v4w77.sh
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Creating Certificate: qs.app
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Creating Site: qs.app
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: inline script
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Checking for old Schedule
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Clear Variables
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Restarting Cron
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Restarting Nginx
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Creating MySQL Database: homestead
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Creating Postgres Database: homestead
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: script: Update Composer
    homestead-7: You are running composer as "root", while "/home/vagrant/.composer" is owned by "vagrant"
    homestead-7: You are already using composer version 1.7.3 (stable channel).
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: C:/Users/halo/AppData/Local/Temp/vagrant-shell20181118-11516-19i1sgw.sh
==> homestead-7: Running provisioner: shell...
    homestead-7: Running: C:/Users/halo/AppData/Local/Temp/vagrant-shell20181118-11516-k8nfh2.sh

Vagrant box version v6.4.0

PS C:\Users\halo\PhpStormProjects\homestead> vagrant box update --provider=hyperv
==> homestead-7: Checking for updates to 'laravel/homestead'
    homestead-7: Latest installed version: 6.3.0
    homestead-7: Version constraints:
    homestead-7: Provider: hyperv
==> homestead-7: Updating 'laravel/homestead' with provider 'hyperv' from version
==> homestead-7: '6.3.0' to '6.4.0'...
==> homestead-7: Loading metadata for box 'https://vagrantcloud.com/laravel/homestead?access_token=pPxaV3VGRDshjA.atlasv1.8sQMWGwfMOqh8zeyF6TI9gH88SDXzC9LliShzHyK6GNCIxxvyEcNVClfySCLMqNd6V0'
==> homestead-7: Adding box 'laravel/homestead' (v6.4.0) for provider: hyperv
    homestead-7: Downloading: https://vagrantcloud.com/laravel/boxes/homestead/versions/6.4.0/providers/hyperv.box
==> homestead-7: Box download is resuming from prior download progress
    homestead-7: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    homestead-7:
==> homestead-7: Successfully added box 'laravel/homestead' (v6.4.0) for 'hyperv'!

cbj4074 commented 5 years ago

Thanks for taking a look.

I'm pretty sure that only adds the box to your host; it doesn't "upgrade" the existing VM that you provisioned with box 6.3.0. You would have to vagrant destroy && vagrant up after upgrading the box.

To be thorough, what happens if you completely destroy the VM, and hard-code the box version at the top of your Homestead.yaml file, e.g.:

version: 6.4.0

and then vagrant up?

Also, what happens if you go into Hyper-V Manager, click Import Virtual Machine (in the right-hand pane) and browse to the box directory, which should be C:\Users\halo\.vagrant.d\boxes\laravel-VAGRANTSLASH-homestead\6.4.0\hyperv on your machine?

When I do this, I see No virtual machine files found. But if I go up a level and try the same thing with the directory for version 6.3.0, Hyper-V Manager "sees" the box.

So, there is some fundamental difference between these box versions that is causing Hyper-V not to recognize 6.4.0.

svpernova09 commented 5 years ago

I'm pretty sure that only adds the box to your host; it doesn't "upgrade" the existing VM that you provisioned with box 6.3.0. You would have to vagrant destroy && vagrant up after upgrading the box.

This is correct. There is no way to upgrade an existing VM to a new base box. Is that what you're original question was? if so I missed it, Sorry!

cbj4074 commented 5 years ago

Thanks again for the reply @svpernova09 .

No; all I'm trying to do is provision a new VM with box 6.4.0. I was referring to the output that you showed in your previous post when I said that it didn't demonstrate a working VM on 6.4.0.

Sorry, I should have been more clear in the original issue that the problem seems to be with provisioning a new box on 6.4.0, specifically.

Are you able to do this successfully?

svpernova09 commented 5 years ago

Sorry, I should have been more clear in the original issue that the problem seems to be with provisioning a new box on 6.4.0, specifically.

Are you able to do this successfully?

So steps to reproduce would be:

vagrant up a clean box
Add a site or other Homestead.yaml adjustment
vagrant provision should be successful?

Not all of the scripts in Homestead are designed with idem-potency in mind so vagrant provision is always somewhat of a dice roll depending on several factors. This is why I always want a destroy before an up. I'll give this a shot later today.

cbj4074 commented 5 years ago

Even simpler; steps to reproduce are merely:

vagrant up a clean 6.4.0 box with Hyper-V provider

I'm not trying to re-provision an existing box. I should have used more appropriate terminology... maybe it would be better to use the term "Import", i.e., Import fails with Hyper-V provider on box 6.4.0?

Thanks for your willingness to try it on your machine!

svpernova09 commented 5 years ago

Ah ok, well I was able to vagrant up a new 6.4.0 box on Hyper-V but I did not try to halt it and up again. will test that.

cbj4074 commented 5 years ago

Hmm, okay, I can't even get that far. For me, it fails upon the initial vagrant up:

PS C:\Users\bjohnson\Work\Web\homestead-fresh> vagrant up
Bringing machine 'homestead-7' up with 'hyperv' provider...
==> homestead-7: Verifying Hyper-V is enabled...
==> homestead-7: Verifying Hyper-V is accessible...
==> homestead-7: Box 'laravel/homestead' could not be found. Attempting to find and install...
    homestead-7: Box Provider: hyperv
    homestead-7: Box Version: 6.4.0
==> homestead-7: Loading metadata for box 'laravel/homestead'
    homestead-7: URL: https://vagrantcloud.com/laravel/homestead
==> homestead-7: Adding box 'laravel/homestead' (v6.4.0) for provider: hyperv
    homestead-7: Downloading: https://vagrantcloud.com/laravel/boxes/homestead/versions/6.4.0/providers/hyperv.box
    homestead-7: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    homestead-7:
==> homestead-7: Successfully added box 'laravel/homestead' (v6.4.0) for 'hyperv'!
==> homestead-7: Importing a Hyper-V instance
    homestead-7: Creating and registering the VM...
An error occurred while executing a PowerShell script. This error
is shown below. Please read the error message and see if this is
a configuration error with your system. If it is not, then please
report a bug.

Script: import_vm.ps1
Error:

Failed to import a virtual machine.

Error Code: 32784
Cause: VM version is unsupported

Initially, there was no error code or message, but Vagrant 2.2.1 fixed that, so at least now we know the reason code, which is 32784. This code comes directly out of WMI (it's not a Vagrant error, per se). I've done some digging and and have yet to find anything useful that describes what, exactly, that code means. There's more info in the linked issue.

I notice that you have a slightly newer version of Windows 10, which appears to use Hyper-V configuration version 9, whereas mine is 8.3. I'm not sure that this matters, but it's worth noting, especially if that box was "baked" using configuration version 9.0.

svpernova09 commented 5 years ago

I notice that you have a slightly newer version of Windows 10, which appears to use Hyper-V configuration version 9, whereas mine is 8.3. I'm not sure that this matters, but it's worth noting, especially if that box was "baked" using configuration version 9.0.

I bet that's exactly the issue. I'm on retail Windows 10 Pro no insider builds or early access to anything. Do you have any pending Windows updates?

If you're feeling brave I could walk you through trying to build your own box for your 8.3 system. (would be available after 5pm CST today at the earliest)

cbj4074 commented 5 years ago

The machine is in question is in a corporate setting (Windows 10 Enterprise) and updates are controlled via policy (WSUS, I believe), so while Windows reports that no updates are available, it seems likely that the "October 2018 Update" (version 1809) is being withheld for whatever reason.

What's the downside of creating the official box with a lower Hyper-V Configuration version, such as 8.0? Is there any feature of 9.0 that Homestead requires, specifically?

As I understand it, Hyper-V can import VMs with any lower Configuration version, so it seems like the official Homestead box should use the lowest version that is actually required for it to function as intended.

While I haven't tried building a box for Hyper-V, it looks like the Configuration version is specified via simple switch.

If for whatever reason that isn't an option, I suppose I'll have to either a) convince the powers that be to push out Windows 1809, or b) build my own box that requires Configuration version 8.3.

In the interest of supporting the largest user-base possible, it seems like lowering the version requirement would be ideal; lots of folks have yet to make the leap to the October 2018 Update, given all the problems that have appeared in the wild.

Curious to hear your thoughts on this... thanks again!

svpernova09 commented 5 years ago

I try to only support the latest version of things. It's just easier on me but it doesn't always work (We currently don't support latest VMware for example) which is why I use a retail version of 10 and keep it up to date.

AFAIK there is nothing specific about Hyper-V versions and Homestead. My best advice would be to install https://packer.io and give http://github.com/laravel/settler/ a spin to build your own box. The output should be a box file you can use and specify in your Homestead.yaml as box: myvagrantbox to use that box instead of the real Homestead base box. The trouble here is now you're Homestead compatible so long as we don't change anything in the repo that would need a base box. Ultimately you'd need to build a fresh box everytime we release one to stay up to date. It's not a hard process, but can be daunting.

Like I said I'm happy to walk you through the process if needed.

cbj4074 commented 5 years ago

No problem at all, that's perfectly understandable.

I'll give Packer a whirl and reach-out if I get stuck anywhere.

I don't mind having to build a fresh box with each upstream release, especially given that it's a short-term solution until we receive that update to Windows 1809.

Is it worth adding something to the Homestead documentation that explains the relationship between the Windows/Hyper-V Configuration version and the Homestead box? That would have saved me quite a bit of time on Friday. ;)

Thanks again for the responsiveness and assistance!

svpernova09 commented 5 years ago

Gotcha, let me know if you run into issues w/ Packer.

cbj4074 commented 5 years ago

Having fiddled with this for a few days now, Packer and Settler seem straightforward, but I have yet to produce a successful build.

While issues 1 and 3 have nothing to do with Homestead, I figured I'd document them all the same.

1.) More often than not, the build fails immediately after systemd is updated. Given the erratic nature of this issue, it feels like a race-condition of some kind. (The problem appears not to occur on Ubuntu 16.04 LTS, which isn't surprising, given that it doesn't use systemd by default.) When it happens, the output looks like this:

hyperv-iso: Setting up systemd (237-3ubuntu10.9) ...
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [ERROR] Remote command exited without exit status or exit signal.
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [INFO] RPC endpoint: Communicator ended with: 2300218
2018/11/21 08:57:55 [INFO] 979 bytes written for 'stderr'
2018/11/21 08:57:55 [INFO] 32064 bytes written for 'stdout'
2018/11/21 08:57:55 [INFO] RPC client: Communicator ended with: 2300218
2018/11/21 08:57:55 [INFO] RPC endpoint: Communicator ended with: 2300218
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [INFO] 979 bytes written for 'stderr'
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [INFO] 32064 bytes written for 'stdout'
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [INFO] RPC client: Communicator ended with: 2300218
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [DEBUG] Opening new ssh session
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [ERROR] ssh session open error: 'read tcp 192.168.90.186:50141->192.168.90.72:22: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.', attempting reconnect
2018/11/21 08:57:55 packer.exe: 2018/11/21 08:57:55 [DEBUG] reconnecting to TCP connection for SSH
2018/11/21 08:58:10 packer.exe: 2018/11/21 08:58:10 [ERROR] reconnection error: dial tcp 192.168.90.72:22: i/o timeout
2018/11/21 08:58:10 packer.exe: 2018/11/21 08:58:10 Retryable error: Error removing temporary script at /tmp/script_7927.sh: dial tcp 192.168.90.72:22: i/o timeout
2018/11/21 08:58:12 packer.exe: 2018/11/21 08:58:12 [DEBUG] Opening new ssh session
2018/11/21 08:58:12 packer.exe: 2018/11/21 08:58:12 [ERROR] ssh session open error: 'client not available', attempting reconnect
2018/11/21 08:58:12 packer.exe: 2018/11/21 08:58:12 [DEBUG] reconnecting to TCP connection for SSH
2018/11/21 08:58:27 packer.exe: 2018/11/21 08:58:27 [ERROR] reconnection error: dial tcp 192.168.90.72:22: i/o timeout

2.) There's some issue with lucky_cli-0.11.0 that causes an exception during the build. It looks like this:

    hyperv-iso: lucky_cli-0.11.0/src/web_app_skeleton/tasks/create_required_seeds.cr
    hyperv-iso: lucky_cli-0.11.0/src/web_app_skeleton/tasks/create_sample_seeds.cr
    hyperv-iso: Fetching https://github.com/mosop/teeplate.git
    hyperv-iso: Installing teeplate (0.6.1)
    hyperv-iso: + crystal build src/lucky.cr --release --no-debug
    hyperv-iso: Error in src/lucky.cr:2: while requiring "./lucky_cli"
    hyperv-iso:
    hyperv-iso: require "./lucky_cli"
    hyperv-iso: ^
    hyperv-iso:
    hyperv-iso: in src/lucky_cli.cr:2: while requiring "./lucky_cli/**"
    hyperv-iso:
    hyperv-iso: require "./lucky_cli/**"
    hyperv-iso: ^
    hyperv-iso:
    hyperv-iso: in src/lucky_cli/browser_src_template.cr:4: macro didn't expand to a valid program, it expanded to:
    hyperv-iso:
    hyperv-iso: ================================================================================
    hyperv-iso: --------------------------------------------------------------------------------
    hyperv-iso:    1.       def ____collect_files(____files)
    hyperv-iso:    2. ____files << ::Teeplate::Base64Data.new("src/queries/user_query.cr", 38_u64, <<-EOS
    hyperv-iso:    3. Y2xhc3MgVXNlclF1ZXJ5IDwgVXNlcjo6QmFzZVF1ZXJ5CmVuZAo=
    hyperv-iso:    4. EOS
    hyperv-iso:    5. , File::Permissions.from_value(436))
    hyperv-iso:    6. ____files << ::Teeplate::Base64Data.new("src/emails/password_reset_request_email.cr", 397_u64, <<-EOS
... nearly 1000 more lines in dump, ending with ...
    hyperv-iso:  843. ZHVsZXMvbGFyYXZlbC1taXgvc2V0dXAvd2VicGFjay5jb25maWcuanMiCiAg
    hyperv-iso:  844. fQp9Cg==
    hyperv-iso:  845. EOS
    hyperv-iso:  846. , File::Permissions.from_value(436))
    hyperv-iso:  847. end
    hyperv-iso:  848. def __ecr2(____io)
2018/11/27 10:03:06 packer.exe: 2018/11/27 10:03:06 [INFO] 135686 bytes written for 'stderr'
2018/11/27 10:03:06 packer.exe: 2018/11/27 10:03:06 [INFO] RPC client: Communicator ended with: 1
    hyperv-iso:  849.   ::ECR.embed "/home/vagrant/lucky_cli-0.11.0/src/browser_app_skeleton/src/emails/templates/password_reset_request_email/html.ecr.ecr", "____io"
    hyperv-iso:  850. end
    hyperv-iso:  851. def __ecr4(____io)
    hyperv-iso:  852.   ::ECR.embed "/home/vagrant/lucky_cli-0.11.0/src/browser_app_skeleton/src/emails/templates/password_reset_request_email/text.ecr.ecr", "____io"
    hyperv-iso:  853. end
    hyperv-iso:  854.
    hyperv-iso: --------------------------------------------------------------------------------
    hyperv-iso: Syntax error in expanded macro: directory:5: expecting token ')', not ','
    hyperv-iso:
    hyperv-iso: , File::Permissions.from_value(436))
    hyperv-iso: ^
    hyperv-iso:
    hyperv-iso: ================================================================================
    hyperv-iso:
    hyperv-iso:   directory "#{__DIR__}/../browser_app_skeleton"
    hyperv-iso:   ^~~~~~~~~
    hyperv-iso:
2018/11/27 10:03:06 [INFO] (telemetry) ending shell

I'm surprised that this happens to me but not to you, as the problem seems specific to that version of lucky_cli.

Modifying homestead.sh to require v0.12.0 instead fixes the issue.

3.) I get Connection refused during the on-my-zsh installation:

    hyperv-iso: + git clone git://github.com/robbyrussell/oh-my-zsh.git /home/vagrant/.oh-my-zsh
    hyperv-iso: Cloning into '/home/vagrant/.oh-my-zsh'...
    hyperv-iso: fatal: unable to connect to github.com:
    hyperv-iso: github.com[0: 192.30.255.112]: errno=Connection refused
    hyperv-iso: github.com[1: 192.30.255.113]: errno=Connection refused
    hyperv-iso:
2018/11/27 10:39:41 packer.exe: 2018/11/27 10:39:41 [ERROR] Remote command exited with '128': echo 'vagrant' | HOME_DIR='/home/vagrant' PACKER_BUILDER_TYPE='hyperv-iso' PACKER_BUILD_NAME='hyperv-iso' PACKER_HTTP_ADDR='192.168.90.186:8952' http_proxy='' https_proxy='' no_proxy=''  sudo -S -E sh -eux '/tmp/script_714.sh'
2018/11/27 10:39:41 packer.exe: 2018/11/27 10:39:41 [INFO] RPC endpoint: Communicator ended with: 128
2018/11/27 10:39:41 [INFO] 176533 bytes written for 'stderr'
2018/11/27 10:39:41 [INFO] 275377 bytes written for 'stdout'
2018/11/27 10:39:41 [INFO] RPC client: Communicator ended with: 128
2018/11/27 10:39:41 [INFO] RPC endpoint: Communicator ended with: 128
2018/11/27 10:39:41 packer.exe: 2018/11/27 10:39:41 [INFO] 176533 bytes written for 'stderr'
2018/11/27 10:39:41 packer.exe: 2018/11/27 10:39:41 [INFO] 275377 bytes written for 'stdout'
2018/11/27 10:39:41 packer.exe: 2018/11/27 10:39:41 [INFO] RPC client: Communicator ended with: 128
2018/11/27 10:39:41 [INFO] (telemetry) ending shell

I thought that this may be some transient condition, but the failure occurs in the same place every time.

To fix this, I had to force Git to use https over the git protocol, which I did by adding this to the top of homestead.sh:

git config --global url."https://github.com".insteadOf git://github.com

I'm not behind a proxy, but clearly the issue is related to SSH, so maybe an appliance on our corporate network is interfering for whatever reason.

4.) rbenv installation fails:

    hyperv-iso: + git clone https://github.com/rbenv/rbenv.git /home/vagrant/.rbenv
    hyperv-iso: Cloning into '/home/vagrant/.rbenv'...
    hyperv-iso: + echo export PATH="$HOME/.rbenv/bin:$PATH"
    hyperv-iso: + echo eval "$(rbenv init -)"
    hyperv-iso: + exec /bin/bash
    hyperv-iso: /bin/bash: line 1: vagrant: command not found
2018/11/27 11:49:19 packer.exe: 2018/11/27 11:49:19 [ERROR] Remote command exited with '127': echo 'vagrant' | HOME_DIR='/home/vagrant' PACKER_BUILDER_TYPE='hyperv-iso' PACKER_BUILD_NAME='hyperv-iso' PACKER_HTTP_ADDR='192.168.90.186:8519' http_proxy='' https_proxy='' no_proxy=''  sudo -S -E sh -eux '/tmp/script_9206.sh'

As with issue 2, it seems like this isn't specific to my configuration, and I'm surprised this doesn't happen to you.

It looks like you added this in https://github.com/laravel/settler/commit/b2644a1b45904a5d2703ab4d87a21c1ee284e752 (tagged with v6.4.0), so maybe I should try using v6.3.0.

In any case, I'll keep at it, but issues 2 and 4 seem like bugs.

svpernova09 commented 5 years ago

Looks like Settler is out of date / I forgot to push changes.

Pull the latest version of master from settler, then run ./bin/copy-to-bento.sh again and give packer another spin.

cbj4074 commented 5 years ago

Thanks! The build is working for me now, with those problematic lines commented-out. 👍

Out of curiosity, do you ever experience the systemd issue that I noted as 1), above?

I just keep re-running the build script and eventually the condition doesn't occur and it finishes. It's difficult to know whether it's a problem with Packer, or some other component (clearly, nothing to do with Homestead nor Settler, though).

In any case, I think I'm all set here, although, I still think it's worth adding something to the Homestead documentation that correlates box versions with Hyper-V configuration versions, i.e., some kind of a table/matrix.

Even though Vagrant improved the error reporting in this scenario with v2.2.1, the message is still too generic for most people to realize the actual problem, which is that the box's Hyper-V configuration version is too new for their Windows build, which is what determines the Hyper-V supported configuration version.

I'm happy to submit a PR if this is of interest.

And just in case anybody else ever has a need to go the route that I have, once built, the custom box can be added to vagrant like this:

vagrant box add homestead-custom file:///c:/some/path/bento/builds/ubuntu-18.04.hyperv.box

(the name is arbitrary; it just has to match the line in Homestead.yaml, e.g., box: homestead-custom)

As a final point of note, it seems necessary to comment-out the line that defines config.vm.box_version in scripts/homestead.rb (within the Homestead repo), or Vagrant complains with You specified a box version constraint with a direct box file path...

Thanks again for helping me sort this, and let me know if a PR regarding a version matrix would be considered, and if so, which document I should direct it towards.

LiBraga commented 5 years ago

FYI... everything would have been fine... except MS keep pulling the v1809 update (its the one that sometimes deleted user files). Also note Windows 10 Enterprise is on a different update branch than Home/Business and tend to receive feature based updates on a later schedule (prior to v17, this may have changed with the closer integration of Business and Enterprise from versions 17 onwards). If you'd like to update to v1809 then please follow this link (if it's not showing is WSUS/SCCM/Windows Updates etc) https://www.microsoft.com/en-us/software-download/windows10

cbj4074 commented 5 years ago

@svpernova09 Sorry to "bump" my question to you in my previous comment, but have you encountered this pesky systemd failure?

Every time I have to update my custom box (that is, rebuild it from the latest sources), I'd say 4 out of 5 attempts fail with this systemd issue. If I just keep trying, the build succeeds eventually, which to me smells of an intermittent bug, likely a race-condition.

I'm not suggesting in any way that it's Homestead-specific -- quite the opposite -- I'm just wondering if this happens to you, too, and if so, if you're aware of any existing Issue/ticket that documents the behavior. I'd like to open one if it doesn't exist, but I'm not sure whether it's a Packer issue, an Ubuntu issue, or something else entirely.

Any insight you may have would be appreciated greatly.

svpernova09 commented 5 years ago

@svpernova09 Sorry to "bump" my question to you in my previous comment, but have you encountered this pesky systemd failure?

The specific error there I think was due to me being dumb in regards to ruby.

This is still happening for you on the latest master of settler? I recently built a custom box based on settler 6.4 and didn't have any any issues building it for Virtualbox or VMware. I'll kick off a hyper-v build here in a minute and see if anything happens.

I'm not suggesting in any way that it's Homestead-specific -- quite the opposite -- I'm just wondering if this happens to you, too, and if so, if you're aware of any existing Issue/ticket that documents the behavior. I'd like to open one if it doesn't exist, but I'm not sure whether it's a Packer issue, an Ubuntu issue, or something else entirely.

Feel free to open a new issue, happy to keep it open until we can see if I can duplicate in Hyper-V on my end.

svpernova09 commented 5 years ago

@cbj4074

So looks like the Hyper-V build I kicked off earlier completed fine. No errors to speak of.

cbj4074 commented 5 years ago

@svpernova09 Okay, thanks for checking! I really appreciate it.

It may very well be an issue with my network configuration. If I ever discover the cause, I'll let you know!

enderandpeter commented 5 years ago

I'm sad to say that I'm suffering this problem, unable to get Homestead running in a Windows environment with Hyper-V.

I got further along setting version: 6.3.0 in my Homestead.yaml, but it ran into an error in the provisioning when it said Unable to locate package mariadb-server-10.3 and then could not start the mysql service.

Does that version pertain to the vagrant box version, 7.1.0 at the time of writing this? If so, I'd love to know how to get the current version to not error out with Error Code: 32784 Cause: VM version is unsupported.

Update

I have been able to use homestead via version 6.3.0 after making sure my vagrant box folder was on a drive with sufficient space. But I'm still running into that error above for version 7.1.0.

svpernova09 commented 5 years ago

The error you are seeing relates to the version of Hyper-V windows has. This varies by patch and can even get odd when you have group policies from a windows admin that may also hold back updates or flat out disable things. I believe you need to upgrade windows or let updates install. The only hyper-v version I’m able to support is whatever the retail windows has at the time I build the box.

--

Joe Ferguson JoeFerguson.me osmihelp.org On Mar 17, 2019, 13:54 -0400, Spencer Williams notifications@github.com, wrote:

I'm sad to say that I'm suffering this problem, unable to get Homestead running in a Windows environment with Hyper-V. I got further along setting version: 6.3.0 in my Homestead.yaml, but it ran into an error in the provisioning when it said Unable to locate package mariadb-server-10.3 and then could not start the mysql service. Does that version pertain to the vagrant box version, 7.1.0 at the time of writing this? If so, I'd love to know how to get the current version to not error out with Error Code: 32784 Cause: VM version is unsupported. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

cbj4074 commented 5 years ago

@enderandpeter Which Windows build are you running? You can check under Start menu -> Settings (the gear icon) -> System -> About, and look under the Windows specifications heading.

If you have Version 1803, then you are in the same boat as I am.

The simplest "solution" is to upgrade Windows 10 to the latest release, which is build 1809, also known as "Windows 10 October 2018 Update". If Windows Update isn't presenting you with the update, you can try installing it manually with the link cited in https://github.com/laravel/homestead/issues/974#issuecomment-444049483 .

If you can't or don't want to upgrade, your only other option is to build the Homestead box yourself, which is what I ended-up doing. The process is fairly simple, but there are several snags that you may hit, all of which I detail elsewhere in my comments on this Issue.

I'm happy to share the .box file I built with you, too, if you'd prefer, which would save you the trouble of installing the tools required to build the box (Packer, Bento, etc.).

Let me know if you want the .box file and I'll make it available to you.

mludi commented 5 years ago

I have still the same issue with Windows in version 1809 :/

cbj4074 commented 5 years ago

@mludi

1809 has the same issue :/

Could you be a bit more specific?

Are you referring to this message?

Error Code: 32784 Cause: VM version is unsupported

Or the MariaDB error?

mludi commented 5 years ago

Oh yeah sorry, I typed fast on my phone. I hvae the MariaDB error. There was some output

401 unauthenticated for the APT package manager, double checked all network settings but no luck. I'll try soon again and post the output here.

My homestead version is v7.1.0

mludi commented 5 years ago

So, I tried again:

    homestead-7: 182268 files and directories currently installed.)
    homestead-7: Removing mysql-server-core-5.7 (5.7.25-0ubuntu0.18.04.2) ...
    homestead-7: Removing mysql-client-core-5.7 (5.7.25-0ubuntu0.18.04.2) ...
    homestead-7: Removing libaio1:amd64 (0.3.110-5) ...
    homestead-7: Removing libcgi-fast-perl (1:2.13-1) ...
    homestead-7: Removing libhtml-template-perl (2.97-1) ...
    homestead-7: Removing libcgi-pm-perl (4.38-1) ...
    homestead-7: Removing libevent-core-2.1-6:amd64 (2.1.8-stable-4build1) ...
    homestead-7: Removing libfcgi-perl (0.78-2build1) ...
    homestead-7: Processing triggers for libc-bin (2.27-3ubuntu1) ...
    homestead-7: Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
    homestead-7: Reading package lists...
    homestead-7: Building dependency tree...
    homestead-7: Reading state information...
    homestead-7: Warning: apt-key output should not be parsed (stdout is not a terminal)
    homestead-7: Executing: /tmp/apt-key-gpghome.LOhCbN9Cji/gpg.1.sh --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
    homestead-7: gpg: keyserver receive failed: No data
    homestead-7: Err:1 http://ppa.launchpad.net/nginx/development/ubuntu bionic InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:2 http://archive.ubuntu.com/ubuntu bionic InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:5 http://security.ubuntu.com/ubuntu bionic-security InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:6 http://ppa.launchpad.net/ondrej/php/ubuntu bionic InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:7 http://packages.blackfire.io/debian any InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
    homestead-7: Err:8 http://ftp.osuosl.org/pub/mariadb/repo/10.3/ubuntu bionic InRelease
    homestead-7:   401  Unauthorized [IP: 192.168.10.249 1000]
....
 homestead-7: Couldn't find any package by regex 'mariadb-server-10.3'
    homestead-7: sed: can't read /etc/mysql/my.cnf: No such file or directory
    homestead-7: /tmp/vagrant-shell: line 53: mysql: command not found
    homestead-7: Failed to restart mysql.service: Unit mysql.service not found.
    homestead-7: /tmp/vagrant-shell: line 56: mysql: command not found
    homestead-7: /tmp/vagrant-shell: line 57: mysql: command not found
    homestead-7: /tmp/vagrant-shell: line 58: mysql: command not found
    homestead-7: /tmp/vagrant-shell: line 59: mysql: command not found
    homestead-7: Failed to restart mysql.service: Unit mysql.service not found.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

and much more of that output.

cbj4074 commented 5 years ago

@mludi Thanks for clarifying.

That error is completely unrelated to the subject of this Issue.

The problem you're experiencing is here:

homestead-7: Executing: /tmp/apt-key-gpghome.LOhCbN9Cji/gpg.1.sh --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8 homestead-7: gpg: keyserver receive failed: No data

Generally speaking, this happens for one of the following reasons:

You're behind a proxy.
You're behind a firewall.
DNS is configured incorrectly, such that the VM cannot resolve domain names.

To fix the issue, you need to determine which of these issues is affecting you.

In any case, this isn't a bug in Homestead, and it's not related to this Issue.

For more info, see:

mludi commented 5 years ago

@cbj4074 ok, sorry for breaking this issue here. I'll have a look again and check. Thanks for the respone.

enderandpeter commented 5 years ago

@cbj4074 Ah, I see... I thought I was on the latest Windows because it updated just the other day and Windows Update tells me I am up-to-date, but under System -> About, it says I have Version 1803 of Windows 10 Pro, and I see that 1809 is the current one. Okay, I will download that "Windows 10 October 2018 Update" and hopefully it makes a difference...

enderandpeter commented 5 years ago

I am happy to report that after updating to build 1809, I'm able to use the latest homestead box without error! It is even fine with mariadb now. So I guess that update was the trick. I don't know why it was telling me I was up to date when I wasn't. I had to click Check for Updates a few times for everything to finally finish, but it did. Thanks!

bumbummen99 commented 5 years ago

Lets update then...

cbj4074 commented 5 years ago

@bumbummen99 Not sure what you mean by that.

Are you proposing that we change something in Homestead? Or are you suggesting that users who come to this Issue with the problem I describe update their Windows version?

bumbummen99 commented 5 years ago

@cbj4074 Sorry i did not really mean to contribute to the discussion and i just updated my local Windows installation. I have tried to get homestead running with Hyper-V for the last hours and the last thing i have guessed is to update my OS. I think it would be hepful for others to place a note about that somewhere prominet as on the documentation page on laravel.com.

cbj4074 commented 5 years ago

@bumbummen99 No problem, and no apology needed; I just wanted to be sure I understood the suggestion.

In any case, I agree completely, and in fact, I suggested precisely that in my earlier comment, https://github.com/laravel/homestead/issues/974#issuecomment-439990689 :

Is it worth adding something to the Homestead documentation that explains the relationship between the Windows/Hyper-V Configuration version and the Homestead box? That would have saved me quite a bit of time on Friday. ;)

I even mentioned it again in a subsequent comment, https://github.com/laravel/homestead/issues/974#issuecomment-442214677 :

Thanks again for helping me sort this, and let me know if a PR regarding a version matrix would be considered, and if so, which document I should direct it towards.

@svpernova09 I don't believe you ever responded to that offer. Not at all suggesting the lack of response was intentional... it was probably just lost in the wall of text that I posted in both instances.

Short-and-sweet: Are you amenable to me (or anyone else) submitting a PR against the Homestead documentation that contains a "version matrix" (i.e., table) that documents which versions of Homestead require which versions of Hyper-V (and therefore which versions of Windows)?

svpernova09 commented 5 years ago

@svpernova09 I don't believe you ever responded to that offer. Not at all suggesting the lack of response was intentional... it was probably just lost in the wall of text that I posted in both instances.

Sorry for the radio silence! I've been trying to recover from a big conference :D

Short-and-sweet: Are you amenable to me (or anyone else) submitting a PR against the Homestead documentation that contains a "version matrix" (i.e., table) that documents which versions of Homestead require which versions of Hyper-V (and therefore which versions of Windows)?

Sounds good to me. I'll certainly +1 the PR on the docs repo.

This should also include the stipulation that I only build the Hyper-V box based on the current Windows updates & build version of Windows 10 Professional at the time I build the box (IE - I'm not on the Insider program so my Windows 10 Pro should be reflective of "retail Windows that's kept up to date via Windows Update). It's really the only option without having to support different box versions tied to different Windows builds.

cbj4074 commented 5 years ago

@svpernova09 Perfect! That sounds entirely reasonable and I'll be sure to include that proviso.

And thanks for the speedy reply! Much appreciated, and no problem on the delay. Hope the conference went well!

bumbummen99 commented 5 years ago

@svpernova09 That sounds awesome, thanks alot! If i may ask, how do you handle the current state of Windows updates/versioning for the project? With all the rollout issues with the last updates latest has become a grand definiton. I dont know if you already meant it in your comment but i guess it would be also helpful to see the Build no. the latest release is using.

svpernova09 commented 5 years ago

@bumbummen99,

I define "latest version of Windows" as "On my Windows 10 Pro machine, not using the Windows Insider program, I'm up to date w/ everything Windows Update offers. I'm using stock options as far as Windows Update is concerned"

Here's the system I use:

Screen-Shot-2019-06-13-at-10 36 03

cbj4074 commented 5 years ago

@svpernova09 Just a couple of questions for you.

What's the output from this command on the system pictured above?

PS C:\windows\system32> Get-VMHostSupportedVersion -Default

Name                                    Version IsDefault
----                                    ------- ---------
Microsoft Windows 10 Update/Server 1803 8.3     True

Is the Settler version number always identical to the Vagrant Box version number? Are they one and the same? Or, even if they are coincidentally the same, is it possible that they differ?

svpernova09 commented 5 years ago

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\WINDOWS\system32> Get-VMHostSupportedVersion -Default

Name                                                 Version IsDefault
----                                                 ------- ---------
Microsoft Windows 10 October 2018 Update/Server 2019 9.0     True

PS C:\WINDOWS\system32>

The settler versions will always match the base box versions. They are identical because the tagged version of Settler was what was used to build that base box. There have only been one or two instances where the base box image might have contained a slight difference but I only let that slide for extreme situations (And no one has ever noticed thankfully)

You'll notice the versions of the box on Vagrant Cloud should link to the Settler release version.

bumbummen99 commented 5 years ago

@svpernova09 Ok, but please keep in mind that due to Microsofts update rollout behaviour not everyone will be on the same 'latest' version. I have several Windows machines, some on 1803, 1809 and 1903. My workplace machine is on 1803 and does not even get 1809 offered when searching for it. The latest Build of Windows is 1903 as far as i know.

svpernova09 commented 5 years ago

@svpernova09 Ok, but please keep in mind that due to Microsofts update rollout behaviour not everyone will be on the same 'latest' version. I have several Windows machines, some on 1803, 1809 and 1903. My workplace machine is on 1803 and does not even get 1809 offered when searching for it. The latest Build of Windows is 1903 as far as i know.

Exactly, and that's why I use the closest thing to retail I can. I can't control what your company IT team does to limit your updates. I can only build the image with the most up to date generic configuration I can, which is the same thing I do with MacOS for Virtualbox, VMware Fusion/Desktop, and Parallels.

Hey @vongrippen, do you have any insights on the better way of handling this? Even with Windows staggering update rollouts, I assumed you could manually go check and get the latest update (unless there is a group policy/windows admin policy that restricts what updates you're getting)

I don't see a scenario where Homestead could feasibly support all the different versions since it seems Hyper-V is moving pretty quickly these days (which is good!)

LiBraga commented 5 years ago

Just going to chime in here “I can't control what your company IT team does to limit your updates”

It’s Microsoft who limit the rollout now. It’s not like the good ol days of it just sitting on the WSUS/SCCM server.

It makes situations like this happen unfortunately. Hell… Microsoft are still sitting preventing 1809 for some users.

From: Joe Ferguson notifications@github.com Sent: 13 June 2019 17:45 To: laravel/homestead homestead@noreply.github.com Cc: LiBraga jm.johnson@sky.com; Comment comment@noreply.github.com Subject: Re: [laravel/homestead] Provisioning fails with Hyper-V provider on Windows 10 version 1803 (#974)

@svpernova09 https://github.com/svpernova09 Ok, but please keep in mind that due to Microsofts update rollout behaviour not everyone will be on the same 'latest' version. I have several Windows machines, some on 1803, 1809 and 1903. My workplace machine is on 1803 and does not even get 1809 offered when searching for it. The latest Build of Windows is 1903 as far as i know.

Exactly, and that's why I use the closest thing to retail I can. I can't control what your company IT team does to limit your updates. I can only build the image with the most up to date generic configuration I can, which is the same thing I do with MacOS for Virtualbox, VMware Fusion/Desktop, and Parallels.

Hey @vongrippen https://github.com/vongrippen , do you have any insights on the better way of handling this? Even with Windows staggering update rollouts, I assumed you could manually go check and get the latest update (unless there is a group policy/windows admin policy that restricts what updates you're getting)

I don't see a scenario where Homestead could feasibly support all the different versions since it seems Hyper-V is moving pretty quickly these days (which is good!)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/laravel/homestead/issues/974?email_source=notifications&email_token=AASRMHDGQDNHEMMURJLONS3P2J2QVA5CNFSM4GDIKQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXUJU3Y#issuecomment-501783151 , or mute the thread https://github.com/notifications/unsubscribe-auth/AASRMHHWT37TEEAFX2DO7MLP2J2QVANCNFSM4GDIKQBQ . https://github.com/notifications/beacon/AASRMHB7TLALQ7P2KVRMA5TP2J2QVA5CNFSM4GDIKQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXUJU3Y.gif

svpernova09 commented 5 years ago

@LiBraga

What I mean is in addition to anything Microsoft is doing to delay you getting a Windows update, I can't control what any IT team does to limit what you can / can't get. Two different issues there possibly in play.

cbj4074 commented 5 years ago

I'd like to revisit a possible solution that I mentioned way back in https://github.com/laravel/homestead/issues/974#issuecomment-439960320 :

What's the downside of creating the official box with a lower Hyper-V Configuration version, such as 8.0? Is there any feature of 9.0 that Homestead requires, specifically?

As I understand it, Hyper-V can import VMs with any lower Configuration version, so it seems like the official Homestead box should use the lowest version that is actually required for it to function as intended.

While I haven't tried building a box for Hyper-V, it looks like the Configuration version is specified via simple switch.

We can probably say, with a high degree of confidence, that Homestead does not rely on a Hyper-V configuration version > 8.3 (and possibly even lower than that).

Doesn't the simplest solution seem to be specifying the configuration version as a simple switch/argument when baking the base box? What's the downside to doing so?

That way, Homestead would work just fine, even on much older versions/builds of Windows 10, and none of this would be an issue.

svpernova09 commented 5 years ago

We can probably say, with a high degree of confidence, that Homestead does not rely on a Hyper-V configuration version > 8.3 (and possibly even lower than that). Doesn't the simplest solution seem to be specifying the configuration version as a simple switch/argument when baking the base box? What's the downside to doing so? That way, Homestead would work just fine, even on much older versions/builds of Windows 10, and none of this would be an issue.

I would need to research what the Hyper-V version differences are. I've always used the latest because that meant big features were supported (things we take for granted in other providers).

If lowering the supported version requirement is as simple as adjusting a value in the Packer template, I'm good with that. I wouldn't be interested in trying to downgrade Windows though to accomplish this.

I don't want to officially support anything but the latest versions as much as possible. I'm one dude with finite resources (however I do have a TON of help from awesome people). For me it's just not feasible to support anything other than current patched OS and current / up to date versions of Vagrant & Vagrant adjacent tooling (Providers, Plugins, etc)

vongrippen commented 5 years ago

I'd recommend adjusting the packer template to use Hyper-V version 8.0, which is where the Windows 10 LTSB (Long Term Servicing Branch) is. That's the version you'll probably see in enterprise settings.

Here's a matrix of what Hyper-V versions are supported in different OS versions: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server#supported-virtual-machine-configuration-versions

As for what features are added in each version, there's nothing past 8.0 that should matter for Homestead. There's a matrix here: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server#what-happens-if-i-dont-upgrade-the-virtual-machine-configuration-version

laravel / homestead

Provisioning fails with Hyper-V provider on Windows 10 version 1803 #974

Versions

Host operating system

Homestead.yaml

Vagrant destroy & up output

Expected behavior

Actual behavior

Steps to reproduce

References

Update