Libvirt Experimental

[tomjn]

Creates a PR for libvirt experimentation @jasalt has been working on

Checks

• I've updated the changelog.
• I've tested this PR
• This PR is for the develop branch not the stable branch.
• This PR is complete and ready for review.

[update-docs]

Thanks for opening this pull request! Make sure CHANGELOG.md gets updated with this change, additionally any docs that need updated can be found at https://github.com/Varying-Vagrant-Vagrants/varyingvagrantvagrants.org

GitHub

GitHub - Varying-Vagrant-Vagrants/varyingvagrantvagrants.org: The VVV docs and website

The VVV docs and website. Contribute to Varying-Vagrant-Vagrants/varyingvagrantvagrants.org development by creating an account on GitHub.

[jasalt]

Testing this today, I noted there's something odd with the IO, I don't know if it's with network or disk or what, but provisioning process is quite sluggish with CPU idling after I started adding sites from my earlier VirtualBox config.

Initially thought it was something with Ubuntu US server yesterday as apt upgrade was downloading very slowly eventhough speedtest-cli --secure in the Vagrant box showed correct speeds for the 600/300M residential connection. The provisioning did finish however with two initial sites working (wordpress-one & wordpress-two), but with some additional sites added there seems to be some additional issues that the provisioning is getting stuck.

I'm learning libvirt myself so there might be mistakes, and might need to run back to VBox setup on another laptop to do some work this week but I'll see if I could figure this out eventually.

[jasalt]

Not sure if relevant but provisioning got stuck with some odd warnings.

Site config:

  wordpress-production:
    skip_provisioning: false
    description: "A standard WP install mimicing a production site with test content added from https://github.com/poststatus/wptest/"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    hosts:
      - production.test
    custom:
      install_test_content: true
      wpconfig_constants:
        WP_DEBUG: true
        WP_DEBUG_LOG: true
        WP_DISABLE_FATAL_ERROR_HANDLER: true

Provisioning output:

    default:  ▷ Running the 'site-wordpress-production' provisioner...
    default:  * Pulling down the master branch of https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    default:  * Downloading wordpress-production provisioner, git cloning from https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git into /srv/www/wordpress-production
    default: Cloning into '/srv/www/wordpress-production'...
    default:  * wordpress-production provisioner clone successful
    default: PHP Warning:  Undefined array key "HTTP_HOST" in /srv/www/wordpress-production/public_html/wp-includes/functions.php on line 6334
    default: Warning: Undefined array key "HTTP_HOST" in /srv/www/wordpress-production/public_html/wp-includes/functions.php on line 6334
    default: PHP Notice:  exif_read_data(dsc02085.jpg): Potentially invalid endianess, trying again with different endianness before imminent failure. in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
    default: Notice: exif_read_data(dsc02085.jpg): Potentially invalid endianess, trying again with different endianness before imminent failure. in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
    default: PHP Warning:  exif_read_data(dsc02085.jpg): Illegal IFD size: 2 + 0x534F*12 = 0x3E7B6 > 0x2EE0 in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
    default: Warning: exif_read_data(dsc02085.jpg): Illegal IFD size: 2 + 0x534F*12 = 0x3E7B6 > 0x2EE0 in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
^C==> default: Waiting for cleanup before exiting...

Cancelled after it hung for a while.

[jasalt]

Discarded the wordpress-production site declaration which came from some old unused config anyways and got more promising results.

Provisioner, while diagnosing some slowness at parts still, went through a bunch of custom site declarations that I migrated from earlier VirtualBox config.yml using VVV development branch without errors.

First live site got imported fine (using https://github.com/jasalt/bvv), off to do some client work then with VVV running on libvirt..

GitHub

GitHub - jasalt/bvv: CLI tool automating everyday tasks with VVV (WordPress development environment). Configured with extended config.yml directives, keeping things simple and centralized.

CLI tool automating everyday tasks with VVV (WordPress development environment). Configured with extended config.yml directives, keeping things simple and centralized. - jasalt/bvv

[tomjn]

Note that if libvirt isn't quite there yet and virtualbox is unstable, the docker provider is always an option.

default: PHP Notice:  exif_read_data(dsc02085.jpg): Potentially invalid endianess, trying again with different endianness before imminent failure. in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
default: Notice: exif_read_data(dsc02085.jpg): Potentially invalid endianess, trying again with different endianness before imminent failure. in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
default: PHP Warning:  exif_read_data(dsc02085.jpg): Illegal IFD size: 2 + 0x534F*12 = 0x3E7B6 > 0x2EE0 in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940
default: Warning: exif_read_data(dsc02085.jpg): Illegal IFD size: 2 + 0x534F*12 = 0x3E7B6 > 0x2EE0 in /srv/www/wordpress-production/public_html/wp-admin/includes/image.php on line 940

This is likely happening in user land in PHP so probably not a libvirt issue, but if it was it might file system related. I have no clues beyond that for you though, and I'd expect such weirdness to apply to far more than a JPEG file if that were the case. I know that database engines can be sensitive to that sutf but if you're executing WP Admin PHP that likely rules that out

[jasalt]

@tomjn yes, Docker has been on mind as potential direction too, especially if it's starting to be considered a stable part of VVV (only have had it working on MacOS so far myself for quick testing). Sharing the kernel would be handy on Linux but rootless container engine would be preferrable.

Quick trial before touching libvirt didn't work straight out of box with Debian repo Docker Engine (configured rootless) or Podman (rootless by default), but I'll probably experiment with those approaches a bit later, either if libvirt fails or as a step to getting more efficient setup (no VM).

Thank's for tips.

[jasalt]

Things pretty much working so far but file/folder permissions with virtiofs in the provider script don't seem correct (trying to follow how ownerships are setup with VBox provider):

override.vm.synced_folder 'www/', '/srv/www', owner: 'vagrant', group: 'www-data', type: 'virtiofs'

https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2780/files#diff-1ea02434f746b6d1522cdef3d4a56e57cf2d5a72c5273927746a71eaf06d74fdR725

Leads to /srv/www in the box having ownership vagrant:vagrant (775), while on another install using VBox provider the folder has vagrant:www-data (775) in fully working setup.

For some reason sudo chown -R vagrant:www-data /srv/www/ does not seem to be enough for WP to be able to e.g. write in wp-content eventhough there's group write permission (775).

Quick fix seems to be to run sudo chown -R www-data:www-data /srv/www/ inside the box.

Have been able to accomplish some work with the setup so it's looking positive, continuing and trying to get XDebug also working in a bit.

[tomjn]

Have you considered:

override.vm.synced_folder 'www/', '/srv/www', owner: 'www-data', group: 'www-data', type: 'virtiofs'

[jasalt]

I'll test this override.vm.synced_folder rule a bit later with fresh setup for fixing the ownership.

[jasalt]

XDebug step debugging working almost out of box.

There was log permission issue with following happening often that I haven't seen with VBox provider, e.g. when starting up sudo -u www-data php -a:

Xdebug: [Log Files] File '/var/log/php/xdebug-remote.log' could not be opened.`

Looking at permissions on functional VVV(VBox) setup:

-rw-rw-rw- 1 root root /var/log/php/xdebug-remote.log

With this libvirt setup it is:

-rw-rw-r-- 1 root root /var/log/php/xdebug-remote.log

Fixed by:

chmod 666 /var/log/php/xdebug-remote.log

[jasalt]

Aside, my host system UFW firewall was running and blocked the XDebug connections coming from VM to port 9003 by default.

Inside guest VVV libvirt VM box ip a returns:

$ ip a
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:50:0f:e4 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    altname ens5
    inet 192.168.121.18/24 metric 100 brd 192.168.121.255 scope global dynamic eth0
       valid_lft 2083sec preferred_lft 2083sec
    inet6 fe80::5054:ff:fe50:fe4/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:8a:76 brd ff:ff:ff:ff:ff:ff
    altname enp0s6
    altname ens6
    inet 192.168.56.4/24 brd 192.168.56.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe12:8a76/64 scope link
       valid_lft forever preferred_lft forever

So fixed on host by allowing allowing all traffic from the subnet:

sudo ufw allow from 192.168.121.0/24 to any port 9003
sudo ufw reload

Debugger is stopping at a breakpoint on host as with VBox provider.

[jasalt]

Just small update that I haven't noticed any new issues while working on a couple client sites locally using this setup. XDebug works for stepping and profiling, external database connection from host works as with VBox and so on.

The shared folder permissions with Linux host work bit differently but it has been pretty straightforward with chmod / chown adjustments.

Looking to finish and clean this up in near future before setting PR ready for review.