New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix VirtualBox support #1756
base: master
Are you sure you want to change the base?
Fix VirtualBox support #1756
Conversation
As mentioned here, the patch is necessary. |
Have you tested the |
No, I don't have a libvirt environnement set up. Because the mailing list discussion the patch is referring to libvirt specifically I figured it didn't apply to VB so I made it libvirt only. What is the issue when the device names aren't predictable? I'll give it a try without a reboot. With it it stops at the private key part during the second round, while the first (pre-patch) passes. |
Non-predictable device names are bad and should be avoided whenever possible. The most Debian derivates are using predictable device names; and OMV more or less is forcing it. |
A quick update with some additional findings. Vagrant VB with
And it does not continue, even though the machine is already up and running. Vagrant VB without reload:
Vagrant VB with
And it does not continue, even though the machine is already up and running. It's becoming quite an effort just to get a test/dev machine up and running, but I'll keep digging some more. I'm running Virtualbox 7.0.16, so I'm currently investigating how to properly get the guest additions updating from 6.0.0 to 7.0.16. Maybe that's the cause. |
Quite a puzzle, but I finally found the cause. The device names are not correct (any more), causing the network service to fail. The patch translates This can be seen in
The guest addition version has no impact. I can't tell if the same thing applies to libvirt though. Does the current patch work for you? The reload plugin is also not needed for VirtualBox. The default shell reboot option works. I've updated the patch to reflect this. Let me know if the new device names still work for libvirt and if the reload plugin the still needed for libvirt, and I'll adjust the patch accordingly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to proceed here. For me the libvirt setup is important, so i can not accept PRs that break this.
vagrant/debian/patch.sh
Outdated
@@ -28,7 +28,7 @@ set -e | |||
# Force predictable network device files. | |||
# Note, a reboot is required to take this changes into account. | |||
echo "Patching network configuration ..." | |||
sed --in-place --expression='s/eth0/ens6/' --expression='s/eth2/ens8/' /etc/network/interfaces | |||
sed --in-place --expression='s/eth0/enp0s3/' --expression='s/eth2/enp0s9/' /etc/network/interfaces |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These device names do not match with the altnames
i see on my libvirt based box:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:33:e6:e6 brd ff:ff:ff:ff:ff:ff
altname enp0s6
inet 192.168.121.24/24 metric 100 brd 192.168.121.255 scope global dynamic ens6
valid_lft 3573sec preferred_lft 3573sec
3: ens7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:a7:30:5e brd ff:ff:ff:ff:ff:ff
altname enp0s7
4: ens8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 52:54:00:3e:3b:30 brd ff:ff:ff:ff:ff:ff
altname enp0s8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made the device names variable per provider.
@@ -15,11 +15,6 @@ $ sudo apt-get install nfs-kernel-server | |||
$ sudo apt-get install vagrant | |||
``` | |||
|
|||
4. Install vagrant-reload plugin (https://github.com/aidanns/vagrant-reload/tree/master) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without the plugin i can not deploy the box:
$ vagrant --version
Vagrant 2.4.1
$ vagrant up
Bringing machine 'omv7box' up with 'libvirt' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:
vm:
* The 'reload' provisioner could not be found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, to stop using the reload plugin, you need to add the , reboot: true
argument to the shell provisioner and remove the reload line. You had this in the past, but you changed it for the reload plugin. I suppose because of issues with libvirt. It's not needed for VB though, so I only reverted it for VB.
- Make patch.sh network device names variable, fixes VitualBox (re)boot issues - Made reload plugin libvirt only, not needed for VirtualBox - Use integrated disk support, prevents `VERR_ALREADY_EXISTS` errors Signed-off-by: Age Bosma <age.bosma@proton.me>
|
||
config.vm.provider :libvirt do |prov, overwrite| | ||
overwrite.vm.provision :shell, :path => "patch.sh", :args => ["ens6", "ens8"] | ||
overwrite.vm.provision :reload |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not work for me:
$ vagrant --version
Vagrant 2.4.1
$ vagrant plugin list
vagrant-libvirt (0.12.2, global)
$ vagrant up
Bringing machine 'omv7box' up with 'libvirt' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:
vm:
* The 'reload' provisioner could not be found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strange. You do still have the reload plugin installed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
$ vagrant --version
Vagrant 2.4.1
$ vagrant plugin install vagrant-reload
Installing the 'vagrant-reload' plugin. This can take a few minutes...
Fetching nokogiri-1.16.4-x86_64-linux.gem
Fetching ruby-libvirt-0.8.2.gem
Building native extensions. This could take a while...
Fetching vagrant-reload-0.0.1.gem
Removing nokogiri
Successfully uninstalled nokogiri-1.16.4-x86_64-linux
Successfully uninstalled ruby-libvirt-0.8.2
Installed the plugin 'vagrant-reload (0.0.1)'!
$ vagrant up
Bringing machine 'omv7box' up with 'libvirt' provider...
==> omv7box: Checking if box 'debian/bookworm64' version '12.20231211.1' is up to date...
==> omv7box: Creating image (snapshot of base box volume).
==> omv7box: Creating domain with the following settings...
==> omv7box: -- Name: debian_omv7box
==> omv7box: -- Description: Source: /home/vot/git/openmediavault/vagrant/debian/Vagrantfile
==> omv7box: -- Domain type: kvm
==> omv7box: -- Cpus: 1
==> omv7box: -- Feature: acpi
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you switch from the default reboot shell option to the reload plugin in the past? Is it still needed for libvirt to begin with?
Would you mind testing this by commenting out the reload provisioner line and adding , reboot: true
at the end of the patch shell line? Just like with the VB provider.
The reload plugin dependency could be removed all together if this works now.
The VirtualBox provider did not work as is.
patch.sh
libvirt only, avoids VirtualBox (re)boot issuesVERR_ALREADY_EXISTS
errorsAs far as I can tell, the issue addressed with
patch.sh
only applied to libvirt anyway.The way disk were added caused issues like hashicorp/vagrant#8107. The only 'drawback' of the new way of adding the disks is that they are put in the default VirtualBox location instead of the
disks
folder with the Vagrantfile file.