The (default) generated homestead VM doesn't haven't an IPv4 address and how to fix this

And there is nothing that indicates a failure : neither when the VM is booting

( … )

using the "ifconfig" command, we can see that our adapters do not have an IPv4 address ( whereas we were expecting to be used )

The “lspci” command allows us to see what devices are used. We can see the Ethernet controllers there.


Back to VirtualBox, let's review the network adapters and see if anything can be done to fix this...

We can see the automatic port forwarding rules set by Vagrant/Homestead



Does any other type of network adapter can come to our rescue ?

Some documentation below…

VirtualBox NIC Type

Source: https://www.vagrantup.com/docs/virtualbox/networking.html

You can specify a specific NIC type for the created network interface by using the nic_type parameter. This is not prefixed by virtualbox__ for legacy reasons, but is VirtualBox-specific.

This is an advanced option and should only be used if you know what you are using, since it can cause the network device to not work at all.


Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "",
    nic_type: "virtio"

Virtual networking hardware

Source: https://www.virtualbox.org/manual/ch06.html

For each card, you can individually select what kind of hardware will be presented to the virtual machine. VirtualBox can virtualize the following six types of networking hardware:

AMD PCNet PCI II (Am79C970A);

AMD PCNet FAST III (Am79C973, the default);

Intel PRO/1000 MT Desktop (82540EM);

Intel PRO/1000 T Server (82543GC);

Intel PRO/1000 MT Server (82545EM);

Paravirtualized network adapter (virtio-net).

The PCNet FAST III is the default because it is supported by nearly all operating systems out of the box, as well as the GNU GRUB boot manager. As an exception, the Intel PRO/1000 family adapters are chosen for some guest operating system types that no longer ship with drivers for the PCNet card, such as Windows Vista.

The Intel PRO/1000 MT Desktop type works with Windows Vista and later versions. The T Server variant of the Intel PRO/1000 card is recognized by Windows XP guests without additional driver installation. The MT Server variant facilitates OVF imports from other platforms.

The "Paravirtualized network adapter (virtio-net)" is special. If you select this, then VirtualBox does not virtualize common networking hardware (that is supported by common guest operating systems out of the box). Instead, VirtualBox then expects a special software interface for virtualized environments to be provided by the guest, thus avoiding the complexity of emulating networking hardware and improving network performance. Starting with version 3.1, VirtualBox provides support for the industry-standard "virtio" networking drivers, which are part of the open-source KVM project.

The "virtio" networking drivers are available for the following guest operating systems:

    Linux kernels version 2.6.25 or later can be configured to provide virtio support; some distributions also back-ported virtio to older kernels.

    For Windows 2000, XP and Vista, virtio drivers can be downloaded and installed from the KVM project web page.[30]

VirtualBox also has limited support for so-called jumbo frames, i.e. networking packets with more than 1500 bytes of data, provided that you use the Intel card virtualization and bridged networking. In other words, jumbo frames are not supported with the AMD networking devices; in those cases, jumbo packets will silently be dropped for both the transmit and the receive direction. Guest operating systems trying to use this feature will observe this as a packet loss, which may lead to unexpected application behavior in the guest. This does not cause problems with guest operating systems in their default configuration, as jumbo frames need to be explicitly enabled.

Network Adapter Settings

Source: http://download.parallels.com/desktop/v4/docs/en/Parallels_Desktop_Users_Guide/22249.htm

  •     Shared Networking. Select this option to enable the Network Address Translation (NAT) feature for the virtual machine. In this case, your virtual machine will share whatever network connection is currently used by your physical computer.

  •     Bridged Ethernet. Select this option to allow the virtual machine to access the local network and Internet through one of the network adapters installed on the physical computer. In this case, the virtual machine is treated as a stand-alone computer on the network and should be configured in the same way as a real one. You can choose the physical adapter where the virtual machine adapter will be bridged in the drop-down list below the Bridged Ethernet option.

  •     Host-Only Networking. Select this option to allow the virtual machine to connect to the physical computer and the virtual machines residing on it and to make it invisible outside the physical computer.


Configuring the adapter type through the Vagrant file did not work as it created a third adapter and was ineffective.

But changing manually the NIC adapters in the VirtualBox VM setting and using • Paravirtualized network adapter (virtio-net) finally gave the best results


A word about false-positive and false-negative test-results, and why having a 'negative test-result' means 'passing the test'


I am writing this because I sense there is a (legitimate) misunderstanding about some vocabulary we are using and I would like to try and clarify things. I will use an analogy from everyday life, that you might be familiar with, and I will explain why a POSITIVE test is a FAILED test, whereas a NEGATIVE test is a PASSED test. If it’s already making sense to you, you can pass, otherwise read on. There shouldn’t be any confusion about what is a false-positive test, and what is a false-negative test, which is which, and why they are critical.

First, notice that the usual phrasing is “one is taking a test”, or “one is being tested for something”.

So, when software is taking a test, software is tested “for” regressions.

Let me explain.

RnD and QA-oriented people, when coding automated tests, we are testing software “for” regressions. An analogy being: just like a chemical-test might reveal the presence of a molecule in your blood, a regression-test might reveal some incoherent or wrong behavior coming from the system-under-test.

So the software is really tested “for” regression(s) just like a person is tested “for” pregnancy, alcohol, narcotics or a disease. And, finally, the result of a test comes in two flavors only: positive or negative. And the meaning of this “positive” or “negative” status is:

-          Positive = Anomaly Detected,
-          Negative = Nothing To Report.

Except that we, humans, when dealing with a consumer, we negate this result and we call a negative test, a PASSED test, and we call a positive test, a FAILED test.

But the logic behind it remains the same and we, RnD and QA-oriented people, we must be familiar with it. There are only 4 typical situations, by the end of an anomaly search:

a) we might find some anomaly and be able to reproduce it (positive test),
b) we might not find any, because there aren’t any anomalies (negative test)
c) we might see some anomaly that isn't there, and then reconsider and force the status to PASS (false-positive test, status FORCED),
d) we might miss some (false-negative test).

All things considered,

-          Situation c), on top of causing a tremendous overhead on the QA-oriented people, it might make the product absolutely impossible to tests (eg. like when using non-deterministic algorithms or data structures),
-          Situation d), on top of causing an increased overhead on both RnD and QA-oriented people later in time, it also means “bad press” for the company at one level or another.

Working iteratively at minimizing the occurrences of cases c) and d) is what makes the whole integrated system reliable and our lives easier in the long run.