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

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

References

• https://github.com/hashicorp/vagrant/issues/9317
• https://github.com/hashicorp/vagrant/issues/10384

Versions

• Vagrant: Just installed
• Provider: Virtualbox
• Homestead: You should be on the most recent release branch.

Host operating system

Tested on both Window and Mac.

Homestead.yaml

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

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ../symfony4
      to: /home/vagrant/code

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

databases:
    - homestead

features:
    - mariadb: false
    - ohmyzsh: false
    - webdriver: false

Expected behavior

No error during composer install

Actual behavior

Steps to reproduce

This is the repo to reproduce the bug: https://github.com/ak3l/Cours_Symfony4/tree/bug

Instead following the actual README, do composer install without --no-plugins --no-scripts to get the error.

When I run composer install -vv, I get

 - Installing ocramius/package-versions (1.4.0): Reading /home/vagrant/.composer/cache/files/ocramius/package-versions/9015316288b55423c693c083934dccb5ab72981d.zip from cache
Loading from cache
 Extracting archiveExecuting command (CWD): unzip -qq  '/home/vagrant/code/vendor/ocramius/package-versions/200f6a66a0865848df9170ec0fd15921' -d '/home/vagrant/code/vendor/composer/f1785882'
Plugin installation failed, rolling back

I tried postponing posting this and trying to figure it out myself but I'm several days in and totally out of ideas so hopefully someone can help.

Versions

• Vagrant: 2.1.1
• Provider: Virtualbox
• Homestead: 7.12.0

Host operating system

macOS High Sierra 10.13.6

Processor: 2.9 GHz Intel Core i5 Memory: 16 GB 1867 MHz DDR3 Graphics: Intel Iris Graphics 6100 1536 MB

Homestead.yaml

ip: 192.168.10.20
memory: 4096
cpus: 1
provider: virtualbox
authorize: ~/.ssh/id_rsa.pub
keys:
    - ~/.ssh/id_rsa
folders:
    - map: /Users/driesvints/Sites/beatswitch-web-app
      to: /home/vagrant/code
sites:
    - map: beatswitch.test
      to: /home/vagrant/code/public
      php: "7.1"
databases:
    - homestead
name: beatswitch
hostname: beatswitch

Vagrant destroy & up output

https://gist.github.com/driesvints/26ce2c2ac8cc17f43fde9572b67fcb2a

Expected behavior

I expect requests to take 1-3 seconds max.

I use Homestead for several projects and while performance isn't always "great" it's never terrible slow. However, with this particularly project my Laravel app runs really slow. It's a special setup with Doctrine ORM instead of Eloquent and an extra DynamoDB Local dependency (which I install with after.sh). But that shouldn't affect the performance really.

Actual behavior

Requests take 10-20 seconds approximately.

I tried several things like mysql tuning, different filesystem sync (nfs), memory & cpu increase. But nothing helped. So I'm totally in the dark why this app is performing slow on Homestead while it performs well on the previous custom box and on production.

Steps to reproduce

1. vagrant up
2. Try out the app and everything runs really slow (~10-20s / request)

Extra info

My after.sh script might be useful as well:

#!/bin/sh

## Install Java if it hasn't been installed yet
if ! [ -x "$(command -v java)" ]; then
    sudo apt-get install -fy
    sudo add-apt-repository -y ppa:openjdk-r/ppa
    sudo apt-get update -y
    sudo apt-get install -y openjdk-11-jre-headless
    sudo apt-get install -y openjdk-11-jdk
fi

# Install DynamoDB Local if it hasn't been downloaded yet
if ! [ -d "./dynamodb" ]; then
    mkdir -p dynamodb && cd dynamodb
    wget http://dynamodb-local.s3-website-us-west-2.amazonaws.com/dynamodb_local_latest.tar.gz
    tar -xvzf dynamodb_local_latest.tar.gz
fi

Versions

• Vagrant: 2.2.6
• Provider: Virtualbox
• Homestead: 8.2.1

Host operating system

Windows 10

Homestead.yaml

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

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: C:\Web_Development\Code
      to: /home/vagrant/Code

sites:
    - map: bogeybrain.test
      to: /home/vagrant/Code/BogeyBrain/public

databases:
    - bogeybrain
    
features:
    - mariadb: false
    - mysql8: true

ports:
     - send: 8080
       to: 8080

Vagrant destroy & up output

https://gist.github.com/jfsullivan/8865ea38e4cc47fc878977ae80561cab

Expected behavior

I had Hot Module Reloading (HMR) working via Laravel Mix but then updated Homestead so that I could begin using Mysql 8.0. I run yarn hot and reload my browser window. I would expect to get a HMR connection thru port 8080 as I did before.

Actual behavior

I get the following errors in the browser console....

GET http://bogeybrain.test:8080//css/app.css net::ERR_CONNECTION_REFUSED GET http://bogeybrain.test:8080//js/app.js net::ERR_CONNECTION_REFUSED

I can connect to the site when not using HMR. HMR is setup to access the main page via port 80 and the CSS and JS via port 8080. The main page is loaded but the CSS and JS connections are refused.

I have the following settings in my webpack.mix.js file to setup HRM

    // For Hot Reloading
    mix.options({
        hmrOptions: {
            host: 'bogeybrain.test',  // site's host name 
            port: 8080,
        }
    });

    // // fix css files 404 issue
    mix.webpackConfig({
        // add any webpack dev server config here
        devServer: { 
            proxy: {
                host: '192.168.10.10',  // host machine ip
                port: 8080,
            },
            watchOptions:{
                aggregateTimeout:200,
                poll:5000
            },

        }
    });

Provision/Configure Ubuntu 20.04

You must be on the Homestead branch 20.04. Create a new/blank Ubuntu 20.04 WSL Distribution. Run the new distribution and change directories to where you have Homestead cloned. For me this is /mnt/c/Users/halo/Code/homestead. Run the initial provisioning script to install the base Homestead system. The script will ask you for your WSL username and user group. You should use your username for your user group unless you have specific plans or requirements outside of the scope of Homestead.

$ cd Code/homestead
$ sudo ./bin/wsl-init
[sudo] password for halo:
What is your WSL user name?
halo
What is your WSL user group? (Same as username if you're unsure)
halo
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
...

Create Sites from Homestead Configuration

Add a new top level configuration item in your Homestead.yaml configuration such as:

wsl_sites:
    -   map: vcdt.test
        to: /mnt/c/Users/halo/Code/vcdt/public

$ ./bin/homestead wsl:create-sites

The sites from wsl_sites will be created.

Create Databases from Homestead Configuration

WSL will read from the normal databases configuration in Homestead.yaml

databases:
    - homestead
    - vcdt
    - laminas

$ ./bin/homestead wsl:create-databases
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
WSL Databases have been created!

The databases from databases will be created.

Installing Optional Features

WSL will read from the normal features configuration in Homestead.yaml

features:
    - timescaledb: true

$ ./bin/homestead wsl:apply-features
Using postgresql.conf at this path:
/etc/postgresql/12/main/postgresql.conf

Writing backup to:
/tmp/timescaledb_tune.backup202010041216

Recommendations based on 50.17 GB of available memory and 8 CPUs for PostgreSQL 12
Saving changes to: /etc/postgresql/12/main/postgresql.conf
Command output can be found via: sudo cat ~/.homestead-features/timescaledb.log
WSL features have been configured!

Posting this per @svpernova09 's advice from a laracasts post (linked at bottom)

Versions

• Vagrant:2.2.4
• Provider: Virtualbox Version 5.2.30
• Homestead: 8.0.0-alpha2

Host operating system

OS X Mojave 10.14.5

Homestead.yaml

ip: 192.168.33.50
memory: 4096
cpus: 1
provider: virtualbox
authorize: ~/.ssh/id_rsa.pub
keys:
    - ~/.ssh/id_rsa
folders:
    -
        map: ../
        to: /home/vagrant/code
sites:
    -
        map: my-app.test
        to: /home/vagrant/code/web/public
databases:
    - homestead
name: web
hostname: web

Vagrant destroy & up output

vagrant destroy gist

vagrant up gist

Expected behavior

After vagrant --reload or a vagrant halt && vagrant up I should be able to access my web app at my-app.test.

Actual behavior

1. After vagrant --reload or a vagrant halt && vagrant up, I get this error screen when trying to navigate to my-app.test:

If I run (from OUTSIDE the vagrant box): $ php artisan cache:clear $ php artisan route:cache $ php artisan config:cache $ php artisan view:clear I can get "past" this error screen, but then get a new one saying that "[...]/storage/logs" does not exist and could not be built: Permission Denied:

If I try to run any of those cache clearing commands from INSIDE vagrant (after vagrant ssh), I get this error:

Permissions seem to be a false flag as I've tried changing permissions, etc and the directory definitely does exist.

I haven't found anyway to get any further besides doing vagrant destroy && vagrant up again. But, of course, the errors begin again anytime I do a vagrant reload or vagrant halt && vagrant up or restart my machine, etc.

Steps to reproduce

1. $ vagrant up to bring box up
2. Navigate in browser to your box's mapped url
3. Verify everything is working correctly
4. Run $ vagrant reload or $ vagrant halt && vagrant up
5. Navigate in browser to your box's mapped url again.
6. Facade Root error should appear.

References

I arrived here through these links:

1. https://laracasts.com/discuss/channels/laravel/laravel-app-throwing-exception-after-running-vagrant-reload?page=1
2. https://github.com/laravel/homestead/issues/1174#issuecomment-498104987

In the newest version of homestead (8.0.0) the default PHP version is 7.3. However there seems to be a problem on a freshly provisioned install. NGINX returns a 502 bad gateway when provisioned for php-7.3.

When switching fastcgi_pass unix:/var/run/php/php7.3-fpm.sock; to fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; the site loads fine again.

Error in NGINX log:

2019/01/15 09:15:59 [error] 539#539: *15 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.10.1, server: com.nbs.test, request: "GET /wp-admin/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: "com.nbs.test"

Error in PHP-FPM log:

[15-Jan-2019 09:32:14] WARNING: [pool www] child 904 exited on signal 11 (SIGSEGV - core dumped) after 1006.631644 seconds from start
[15-Jan-2019 09:32:14] NOTICE: [pool www] child 988 started

Error in /var/log/syslog

Jan 15 09:32:14 vagrant kernel: [ 1538.380198] php-fpm7.3[904]: segfault at 7ffdc3952ff8 ip 000055e499dad9e0 sp 00007ffdc3953000 error 6 in php-fpm7.3[55e499b2b000+3e6000]

My debugging skills didn't go any further unfortunately.

Versions

• Vagrant: 2.2.2
• Provider: Virtualbox
• Homestead: 8.0.0
• Homestead box: 7.0.0 (same issue on 6.4.0)

Host operating system

MacOS 10.14.2

Homestead.yaml

---
ip: "192.168.10.10"
name: "Vagrant V2"
hostname: martijn.local
memory: 2048
cpus: 1
provider: virtualbox

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ~/Sites
      to: /home/vagrant/sites
      type: nfs

sites:
    - map: sandbox.test
      to: /home/vagrant/sites/sandbox
    - map: com.nbs.test
      to: /home/vagrant/sites/nbs

Vagrant destroy & up output

https://gist.github.com/martijn94/8bbd717d0c9b29f49068641589eb1d37

Expected behavior

Site loads for a added site

Actual behavior

Nginx returns 502 bad gateway

Steps to reproduce

Provision fresh box with the latest versions of homestead.

Versions

• Vagrant: 2.1.1
• Provider: Virtualbox (5.2.12)
• Homestead: 7.6.0

Host operating system

Windows 10 64-bit

Homestead.yaml

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

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: C:/Users/adehaven/PW/Sandbox
      to: /var/www/html/Sandbox

sites:
    - map: sandbox.test
      to: /var/www/html/Sandbox
      type: apache

databases:
    - sandbox

# blackfire:
#     - id: foo
#       token: bar
#       client-id: foo
#       client-token: bar

# ports:
#     - send: 50000
#       to: 5000
#     - send: 7777
#       to: 777
#       protocol: udp

Expected behavior

Apache service should remain enabled (and Nginx remain disabled), even after destroying SSH session, or running vagrant halt and then vagrant reload/up (with or without computer restart).

Actual behavior

I SSH into Homestead and run the flip command to stop Nginx and start Apache. All Apache sites run normally (Alternatively, I could SSH into Homestead and stop Nginx and start Apache). If I log out of my SSH session, Apache immediately stops working.

Steps to reproduce

1. SSH into Homestead homestead ssh
2. Run flip command (Alternatively, stop Nginx, and then run sudo service apache2 restart)
3. Test site running Apache -- everything should work normally.
4. Log out of the SSH session (Cmd + D)
5. Apache stops working. Refreshing the browser with the test site running doesn't work.
6. SSH into Homestead again homestead ssh and see that Apache is not still running.

According to the docs, the flip command "automatically determines which web server is running, shuts it off, and then starts the other server." It appears that this does not persist longer than the active SSH session.

Update

When I SSH into Homestead, if I run sudo service apache2 status I receive the following failure message:

 sudo service apache2 status
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: failed (Result: exit-code) since Fri 2018-05-25 01:46:50 UTC; 22s ago
  Process: 2463 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 2480 (code=exited, status=1/FAILURE)

May 25 01:46:15 homestead systemd[1]: Starting The Apache HTTP Server...
May 25 01:46:15 homestead apachectl[2463]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 12
May 25 01:46:15 homestead systemd[1]: Started The Apache HTTP Server.
May 25 01:46:50 homestead systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
May 25 01:46:50 homestead systemd[1]: apache2.service: Failed with result 'exit-code'.
lines 1-13/13 (END)

If I then run sudo service apache2 restart my sites load normally until I log out of the SSH session, at which point Apache apparently fails again.

Versions

• Vagrant: 2.0.1
• Provider: Virtualbox
• Homestead: Latest? (Adding box 'laravel/homestead' (v5.0.1) for provider: virtualbox)

Host operating system

Windows 7 Ultimate 64bit, Windows 10 Pro 64bit - both fresh installs.

Expected behavior

After successfully installing Virtualbox, Vagrant and Homestead...

vagrant ssh cd code composer global require "laravel/installer" laravel new test Expect new laravel installation

Actual behavior

laravel command not found

Workaround:

export PATH="~/.composer/vendor/bin:$PATH"

Never had to do this before on many other Homestead installs.

Please note that the Homestead issue tracker is reserved for bug reports and enhancements. We are not always able to debug Vagrant, Provider or Operating System issues, but will do our best to help. Thank you!

Versions

• Virtualbox: 5.2.14 r123301
• Vagrant: 2.1.2
• Provider: Virtualbox
• Homestead: 7.6.2 | 7.9.0 | 7.10.0

A lot of issues can be resolved by simply updating vagrant, provider or homestead.

Note: Virtualbox users, please upgrade to ~5.2. You will show as up-to-date from the ~5.0 version when you About -> Check for Updates. You'll need to download a newer version of Virtualbox.

Host operating system

This is the operating system that you run locally.

Homestead.yaml

---
ip: "192.168.10.10"
memory: 2048
cpus: 2
provider: virtualbox
mariadb: true
ssl: true

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

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

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

databases:
    - testdb
    
# blackfire:
#     - id: foo
#       token: bar
#       client-id: foo
#       client-token: bar

# ports:
#     - send: 50000
#       to: 5000
#     - send: 7777
#       to: 777
#       protocol: udp

Vagrant destroy & up output

Provide a link to a GitHub Gist containing the complete output of vagrant destroy && vagrant up. Do NOT paste the debug output in the issue, just paste the link to the Gist.

Expected behavior

I would expect that after upgrading to unbuntu 18.04 (homestead 7.10.0) that the migration and phpunit run times would not be significantly slower in the newer version. If anything one would expect the run times to be faster in the newer versions.

Actual behavior

The migration and phpunit run times dramatically increased after upgrading to the newer version of homestead.

Steps to reproduce

1. create a decent about of migrations (I have about 25)
2. run migrations in homestead v7.6.2 "time php artisan migrate" (note times) repeat for PHPUnit
3. upgrade homestead to v7.10.0
4. run migrations in homestead v7.10.0 "time php artisan migrate" (note times) repeat for PHPUnit

My migration times were 2.647s on homestead v7.6.2 they went up to 17.747s (these times are greatly different with the exact same migrations, the only difference was the homestead version). The times for phpunit test to execute also dramatically increased which I believe is because of the increased times of the migrations. Most of my unit test took 4 seconds to run on 7.6.2 and now take 20-30s on 7.10.0. This issue appears to have introduced after moving to Ubuntu 18.04

I could reproduce this one two different system (MacBook Pro & Hackintosh) Both running High Serria.

I did not test this in Homestead v7.7.0 or v7.8.0 but noticed this a couple of weeks ago in 7.9.0 but just now was able to get around to testing. Before 7.9.0 I was on 7.6.2.

Versions

• Vagrant: 2.0.1
• Provider: Hyper-V
• Homestead: 7.0.1 (CLI), 5.0.1 (Box)

Host operating system

Windows 10 Pro

Homestead.yaml

---
ip: "172.21.12.10"
memory: 2048
cpus: 1
provider: hyperv
mariadb: true

authorize: c:/Users/arbet/.ssh/id_rsa.pub

keys:
    - c:/Users/arbet/.ssh/id_rsa

folders:
    - map: c:/Users/arbet/Documents/Projects
      to: /home/vagrant/code

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

databases:
    - homestead

# blackfire:
#     - id: foo
#       token: bar
#       client-id: foo
#       client-token: bar

# ports:
#     - send: 50000
#       to: 5000
#     - send: 7777
#       to: 777
#       protocol: udp

Vagrant destroy & up output

GitHub Gist

Expected behavior

It should boot up and create the whole virtual machine, mounting SMB shared folders and provisioning.

Actual behavior

It fails after it tries to mount SMB shared folders. I suspect it can be because of bad SMB username, because I am using a Microsoft account and I don't know what should be the proper SMB username. However the output also says mount error(112): Host is down

Steps to reproduce

1. Enable HyperV on Windows 10 Pro
2. Install Vagrant
3. Add homestead Vagrant box
4. Run vagrant up

References

No.

Please note that the Homestead issue tracker is reserved for bug reports and enhancements. We are not always able to debug Vagrant, Provider or Operating System issues, but will do our best to help. Thank you!

Versions

• Vagrant: 2.2.19
• Provider: Virtualbox 6.1
• Homestead: 13.3.2

Host operating system

macOS Big Sure 11.7.1

Homestead.yaml

ip: 192.168.56.56
memory: 2048
cpus: 2
provider: virtualbox
authorize: ~/.ssh/id_ed25519.pub
keys:
    - ~/.ssh/id_ed25519
folders:
    -
        map: /Users/p4rad0xus/Developer/github_issue
        to: /home/vagrant/code
sites:
    -
        map: homestead.test
        to: /home/vagrant/code/public
databases:
    - homestead
features:
    -
        mysql: false
    -
        mariadb: true
    -
        postgresql: false
    -
        ohmyzsh: false
    -
        webdriver: false
services:
    -
        enabled: [mysql]
name: github-issue
hostname: github-issue

Vagrant destroy & up output

vagrant up https://gist.github.com/p4rad0xus/411623f39b83aaf449f7c85e207a282a#file-vagrant_up

vagrant destroy https://gist.github.com/p4rad0xus/9f0e5bd46f844cd0d9cc8b17553332fb#file-vagrant_destroy

Expected behavior

The command vagrant up should proceed successful and create the named database in the Homestead.yaml.

Actual behavior

The script stoped at the point when the database should be created with the error "Access denied for user 'root'@'localhost'".

Steps to reproduce

1. Create a new Homestead project
2. Set the feature mysql to false and mariadb to true
3. Run vagrant up

MySQL-User-Table

It looks like a password for root@localhost is never set.

MariaDB [(none)]> Select User, Host, Password from mysql.user;

+-------------+-----------+-------------------------------------------+
| User        | Host      | Password                                  |
+-------------+-----------+-------------------------------------------+
| mariadb.sys | localhost |                                           |
| root        | localhost | invalid                                   |
| mysql       | localhost | invalid                                   |
| root        | 0.0.0.0   | *14E65567ABDB5135D0CFD9A70B3032C179A49EE7 |
| homestead   | 0.0.0.0   | *14E65567ABDB5135D0CFD9A70B3032C179A49EE7 |
| homestead   | %         | *14E65567ABDB5135D0CFD9A70B3032C179A49EE7 |
+-------------+-----------+-------------------------------------------+

Hi guys,

Apologies if this has been asked and dismissed before, but I was wondering how much work it would be to have a libvirt provider in additional to parallels and virtualbox?

I ask because if Linux users want to run a Homestead box, they currently have no alternative but to pollute their beautiful freedom-respecting distributions with Oracle's Virtualbox. As we all know, Oracle holds the top three positions in Time's Most Hated Software Companies On The Planet.

So, please consider adding a libvirt provider for us Linux users, and help us ward off the return of Lucifer.

Versions

• Vagrant: Vagrant 2.3.2
• Provider: Virtualbox 7.0.2 r154219 (Qt5.15.2)
• Homestead: laravel/homestead@dev-main (for Virtualbox 7 support)

Host operating system

MacOS Ventura 13.0 (22A380)

My Process

I created a script to stand up boxes, called vbmake.

I run vbmake testing, and the script handles a lot of the boilerplate for me. The resulting "box" file structure looks like this:

testing.box/
  box/
    vendor
    after.sh
    aliases
    composer.json
    composer.lock
    homestead.testing.crt
    Homestead.yaml
    Vagrantfile
  databases/
  sites/
    test.local/
      index.html

I've never run into any of the issues I'll describe in this ticket using this method until after upgrading my Mac to Ventura.

The script generates the Homestead.yml file below.

Homestead.yaml

name: testing.box
hostname: testing

ip: 192.168.56.0
memory: 2048
cpus: 2
provider: virtualbox

ssl: true
authorize: ~/.ssh/id_rsa.pub
keys:
    - ~/.ssh/id_rsa

folders:
    - map: ../sites/test.local
      to: /home/vagrant/sites/test.local

sites:
    - map: test.local
      to: /home/vagrant/sites/test.local

# databases:
#     - homestead

features:
    - mysql:        false
    - mariadb:      false
    - postgresql:   false
    - ohmyzsh:      false
    - webdriver:    false

Hostfile

192.168.56.0    test.local

Vagrant destroy & up output

Gist

Expected behavior

I expect browsing test.local to display the contents of index.html: <h1>Hello World!</h1>

Actual behavior

Browser times out. ping test.local times out.

Things I've tried to debug / More Info

vagrant ssh -> flip -- I thought potentially the box was starting in apache mode instead of nginx, but I was wrong. Neither load the test.local site.

Then I thought that maybe something in the nginx configuration was borked, but it looks ok.

The Network tab of the Virtualbox says Adapter 1 is NAT, and Adapter 2 is Internal Network.

Thank you for looking at this!