Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

Forage
Copy link

@Forage Forage commented May 3, 2024

The VirtualBox provider did not work as is.

  • Made patch.sh libvirt only, avoids VirtualBox (re)boot issues
  • Use integrated disk support, prevents VERR_ALREADY_EXISTS errors

As 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.

@Forage Forage mentioned this pull request May 3, 2024
@votdev
Copy link
Member

votdev commented May 3, 2024

As mentioned here, the patch is necessary.

@votdev
Copy link
Member

votdev commented May 3, 2024

Have you tested the libvirt installation without the vagrant-reload? Does it work? The last time i reworked the Vagrantfile the plugin has to be installed on Ubuntu Linux, otherwise no reboot was done by Vagrant.

@Forage
Copy link
Author

Forage commented May 3, 2024

Have you tested the libvirt installation without the vagrant-reload? Does it work? The last time i reworked the Vagrantfile the plugin has to be installed on Ubuntu Linux, otherwise no reboot was done by Vagrant.

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.

@votdev
Copy link
Member

votdev commented May 3, 2024

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.

@Forage
Copy link
Author

Forage commented May 6, 2024

A quick update with some additional findings.

Vagrant VB with config.vm.provision :reload:

...
==> omv7box: Running provisioner: shell...
    omv7box: Running: /tmp/vagrant-shell20240504-322239-og84vo.sh
    omv7box: Patching network configuration ...
    omv7box: Patching & rebuilding grub configuration ...
    omv7box: Generating grub configuration file ...
    omv7box: Found linux image: /boot/vmlinuz-6.1.0-18-amd64
    omv7box: Found initrd image: /boot/initrd.img-6.1.0-18-amd64
    omv7box: done
==> omv7box: Running provisioner: reload...
==> omv7box: Attempting graceful shutdown of VM...
==> omv7box: Checking if box 'debian/bookworm64' version '12.20240212.1' is up to date...
==> omv7box: Clearing any previously set forwarded ports...
==> omv7box: Clearing any previously set network interfaces...
==> omv7box: Preparing network interfaces based on configuration...
    omv7box: Adapter 1: nat
    omv7box: Adapter 2: hostonly
    omv7box: Adapter 3: hostonly
==> omv7box: Forwarding ports...
    omv7box: 22 (guest) => 2222 (host) (adapter 1)
==> omv7box: Configuring storage mediums...
==> omv7box: Running 'pre-boot' VM customizations...
==> omv7box: Booting VM...
==> omv7box: Waiting for machine to boot. This may take a few minutes...
...

And it does not continue, even though the machine is already up and running.

Vagrant VB without reload:

...
==> omv7box: Running provisioner: shell...
    omv7box: Running: /tmp/vagrant-shell20240504-316006-6hzn6t.sh
    omv7box: Patching network configuration ...
    omv7box: Patching & rebuilding grub configuration ...
    omv7box: Generating grub configuration file ...
    omv7box: Found linux image: /boot/vmlinuz-6.1.0-18-amd64
    omv7box: Found initrd image: /boot/initrd.img-6.1.0-18-amd64
    omv7box: done
==> omv7box: Running provisioner: shell...
    omv7box: Running: /tmp/vagrant-shell20240504-316006-g2fwfg.sh
    omv7box: New password: Retype new password: passwd: password updated successfully
    omv7box: Reading package lists...
    omv7box: Building dependency tree...
...
    omv7box: [ERROR   ] Interface "ens8" not in available interfaces: "lo", "eth0", "eth1", "eth2"
    omv7box: jq: error (at <stdin>:3): Cannot index string with number
    omv7box: Traceback (most recent call last):
...

Vagrant VB with config.vm.provision :shell, :path => "patch.sh", reboot: true:

...
==> omv7box: Running provisioner: shell...
    omv7box: Running: /tmp/vagrant-shell20240504-318713-beyq6w.sh
    omv7box: Patching network configuration ...
    omv7box: Patching & rebuilding grub configuration ...
    omv7box: Generating grub configuration file ...
    omv7box: Found linux image: /boot/vmlinuz-6.1.0-18-amd64
    omv7box: Found initrd image: /boot/initrd.img-6.1.0-18-amd64
    omv7box: done
==> omv7box: Waiting for machine to reboot...

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. vagrant-vbguest isn't an option due to dotless-de/vagrant-vbguest#432.
The step provided here aren't working as I'd like at the moment either: https://wiki.debian.org/VirtualBox#Installing_the_Guest_Additions_on_a_Debian_VM

@Forage
Copy link
Author

Forage commented May 7, 2024

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 eth0 to ens6 and eth2 to ens8, but this should be enp0s3 and enp0s9.

This can be seen in dmesg:

...
[    2.141598] e1000 0000:00:03.0 enp0s3: renamed from eth0
[    2.169119] e1000 0000:00:08.0 enp0s8: renamed from eth1
[    2.189099] e1000 0000:00:09.0 enp0s9: renamed from eth2
...

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.

Copy link
Member

@votdev votdev left a 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.

@@ -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
Copy link
Member

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

Copy link
Author

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)
Copy link
Member

@votdev votdev May 7, 2024

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.

Copy link
Author

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
Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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
...

Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants