(Unfortunately after further testing the use of VMs, at least under VirtualBox, to run different Qgis versions, has been found to be unsatisfactory. It is easy to see from a technical viewpoint how this would be possible in an environment where video, keyboard and mouse environments are emulated, rather than native.
The solution that has been arrived at for now is to use the VM to edit project properties like the rule based styles in an older version of Qgis, while continuing to use the development version for everything else. However should the development version have too many issues to make this work I would be forced to revert to the current release version, since in Linux it appears to be much more difficult to have multiple versions on the same computer simultaneously)
One of the perils of running a beta version of software is that the bugs may make it unusable. This has happened from time to time with Qgis but it has never been as much of a problem as it is with the current version 2.17-master. A bug has been found that freezes Qgis when attempting to edit rule-based styles in data layers. Since all of my layers use rule-based styles (there is a “type” field in each record which is used in all the rules) obviously I have a problem with this version.
Both these VMs are using the host’s folders to access the map content. This also means the overGrive app running on the host will synchronise changes to the NZ Rail Maps Google Drive.
The third VirtualBox VM I have running on this machine is a Windows 7 one. One of the reasons for having it is to give me access to a different Google Drive – this being the one linked to my main email account – which in this case is used for a whole lot of personal stuff. So for example my budget spreadsheet and all of my study materials are on that one. There is also software I need for those purposes which is not available on Linux.
I also had a play with VirtualBox on one of my work computers which has a Wolfdale Celeron E3300 dual core and only 4 GB of RAM. This particular CPU was specially selected at the time of purchase because it supports VT-x (and 64 bit) so it just manages to meet the requirement for hardware assisted virtualisation. The computer is 6 years old and long since ceased to be of any use at home because the 4 GB memory limitation, driven by having only 2 memory slots and unavailability of DIMMs with more than 2 GB on them, means it runs out of steam pretty quickly. Still, with Xubuntu on it which has lower memory footprint than a lot of other Ubuntu based distros, it has managed to set up and run a Windows 10 VM in 1 GB of memory. This has been pretty slow work, but it looks like it should be able to achieve what is needed – and it’s possible I might be able to increase its memory allocation if it can run some of the tasks I currently put on my Xubuntu desktop. It worked surprisingly well with just 1 GB allocated and the host also worked very well with a number of other resource-intensive applications such as Google Earth and Thunderbird running at the same time. It so happens that if I put the VM up to full screen then it is able to adjust the resolution to 1920×1080, but on my home computer where 1680×1050 is the screen resolution, that VM can’t be made to go up to anything higher than 1152×864, so it would seem the Vbox Guest Additions have limited adaptability to different host screen sizes.
Subsequent to this I discovered issues in the Xubuntu VM that were peculiar to it, that were not seen in the Win10 VM, so I switched to the Win10 VM and then investigated whether the screen resolution could be bumped up. It turns out this is possible with the VBoxManage command on the host. Specifically the command VBoxManage setextradata “VM Name” CustomVideoMode1 1680x1050x32 did the trick, and after restarting the VM, the new fullscreen resolution appeared on the display settings. VBoxManage is basically the command line tool for changing all the VM’s settings, although it obviously appears to be a superset of what is available in the GUI.