Virtualisation and Qgis

UPDATE: The below comment does not make a lot of sense as I have since used Virtualbox VMs very extensively to run Qgis and edit maps. Right now I don’t have need to do this, but in the past it has certainly been a major part of the Qgis work that I have done.

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

For now I have set up two VMs to use the current release version of Qgis. One of these is running the same version of Xubuntu as the host and the other is running Windows 10. Since the host now has 24 GB of RAM (3/4 of the maximum of 32 GB the board supports) it is easily possible to run one or even both of these VMs at the same time. I won’t actually need to do this but I did run the Xubuntu one and set up the Win10 one at the same time.
Here you can see the Xubuntu VM running Qgis 2.16. The Maps folder on the host has been shared and after a fashion I was able to work out how to permanently mount this to a Maps folder in the home folder of the user on the VM. So when I save stuff on the VM, it goes back into the right folder on the host (using network shares as the shared folder capability in VirtualBox ran into permissions problems).
And here we have Qgis running on the Windows 10 VM. Again using a mapped network drive, this time drive M mapped to the share. As you can see a key difference is that the Windows 10 guest additions don’t support full automatic resizing of the VM’s display, which becomes a window centred inside the VirtualBox window. 
So at least I can continue working with Qgis (probably preferring the Xubuntu VM, but may need the Win10 one to run IrfanView when needed) until the bug in 2.17 is addressed.

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.