Then I edited Grub to give me a fullscreen- 1920 x 1080.  You just edit /etc/default/grub with an editor run under sudo. I use Gedit but nano will do. Just change the line to this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1920x1080"

followed by

sudo update-grub

and that should be it. Only it didn’t work in my new Ubuntu 24.04 LTS VM. I installed ifconfig from net-tools, connected to it from my Windows PC and copied grub across. I did the same with my older 24.04 LTS VM and compared the two grub files. Both identical yet one works fullscreen and the newer one doesn’t. Any ideas?

VMs are an excellent way to try out other Operating systems, install software and venture outside the comfort zone of a Windows PC and Windows 10.  Many of the screenshots published here in earlier posts have come from Ubuntu 18.04 LTS running in Hyper-V. It takes a minute to fire it up and connect then login.

I learnt to use Linux that way, both via the Ubuntu GUI and terminal commands and much of my 2nd Ebook has been tested on a Raspberry Pi OS running in a VM. Of course it lacks the hardware of the real Pi, so I have to test programs on both, but it’s quite a bit quicker doing a screen grab using the commercial Snagit on my Windows 10 PC.

I can do screen grabs on a PI using scrot, but then I have to upload the image using WinSCP or Putty. It’s not the end of the world but when you are doing a lot, having the image in the Snagit editor ready to copy/paste is a time saver. Also in a similar way, make sure you can do copy/paste via the clipboard and can resize the guest OS (as it’s called). It makes a difference.

I have mine configured so its uses RDP and you can just see the corner of the RDP bar in the Ubuntu image below where I’ve just launched Visual Studio Code.

From a terminal I did ifconfig and got

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.21.212.121  netmask 255.255.240.0  broadcast 172.21.223.255
        inet6 fe80::2b71:6d6b:9a09:9aae  prefixlen 64  scopeid 0x20
        ether 00:15:5d:38:01:03  txqueuelen 1000  (Ethernet)
        RX packets 47317  bytes 69248755 (69.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27622  bytes 1791175 (1.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

and on Windows

C:\Users\David>ping 172.21.212.121

Pinging 172.21.212.121 with 32 bytes of data:
Reply from 172.21.212.121: bytes=32 time<1ms TTL=64
Reply from 172.21.212.121: bytes=32 time<1ms TTL=64
Reply from 172.21.212.121: bytes=32 time<1ms TTL=64
Reply from 172.21.212.121: bytes=32 time<1ms TTL=64

This makes it very handy for testing network servers or if you do web development running a web server locally.

Most Linux development is done on Ubuntu running under Hyper-V on my Windows 10 PC. If you have lots of RAM (and I have a full 64 GB), it’s very convenient. I run Snagit on Windows and this makes it very easy to grab screenshots of the Ubuntu window.

I also have a “Raspberry-pi” running under Hyper-V.  There’s a Raspbian desktop that you can download and run in Hyper-V, VirtualBox or VMWare though I’ve only done Hyper-V. Don’t forget when you are running a Raspberry Pi this way that its x86 based not ARM. That does affect the available software, so it doesn’t behave exactly like a real Pi though often close enough.

Today though I started getting low disk space from my virtual Ubuntu. That’s the problem with virtual machines. When you first setup a Virtual hard disk, you never know just how much disk space you will need.

There’s a terminal command that shows how much space you have left.

df -h --total

This produced this

david@david-Virtual-Machine:~$ df -h --total
Filesystem      Size  Used Avail Use% Mounted on
udev            942M     0  942M   0% /dev
tmpfs           193M  1.4M  192M   1% /run
/dev/sda1        11G  9.9G  603M  95% /
tmpfs           964M     0  964M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           964M     0  964M   0% /sys/fs/cgroup
/dev/sda15      105M  3.6M  101M   4% /boot/efi
tmpfs           193M   16K  193M   1% /run/user/121
tmpfs           193M   24K  193M   1% /run/user/1000
total            14G  9.9G  4.1G  71% -

This was after I’d extended my virtual hard disk.  You can see I now have 4.1 GB free.

The pretty picture is from a utility filelight. You install it in the usual way

sudo apt install filelight

Or if you prefer a more visual insight, install qdirstat.

sudo apt install qdirstat

This is like WinDirStat on Windows but qdirstat seems to run many times faster. It took a couple of seconds to produce this image below. WinDirStat would take 10-30 minutes.

So how did I expand my Hyper-V hard drive?

First you have to get rid of any checkpoints. Save your Hyper-V session if open then delete the checkpoint.

Right click on the checkpoint for the selected VM and click delete. This will take a minute or two and you’ll see it have a Merging status. You may need to shutdown the VM.

After that you can go into the settings and it will let you edit the virtual hard drive and change the size.

Yes it is possible, as the screenshot shows. You can download a copy of Raspbian from Raspberry-pi. You can either download the .iso directly or save them a bit of bandwidth and do it via a file Torrent. It then takes about 15 minutes or so to install it. When you first run it, it will do an update.

It looks exactly like Raspbian on a PI but there are one or two little things to bear in mind. It’s 32-bit, the clipboard doesn’t seem to work and SSH by default is disabled. It’s real easy to enable it, just find Raspberry Pi Configuration. Click the Raspberry in a circle menu button at the top, then click Preferences and there it is on the menu that pops up. In the Interfaces tab, tick the Enabled checkbox for SSH.

I use the excellent WinSCP to connect to it. Conveniently the Pi will show you its ip address (or from a terminal run ifconfig and it will show you the ip address of eth0) and just put that in with username pi and your pi’s password which you should have changed when you set up Raspbian.

Finally you have to install Visual Studio Code and as usual, it’s not quite so easy. Most Linux distros these days are 64-bit and the official VS Code is only available for Debian in 64-bit and Raspbian is of course 32-bit. But there are community builds and it’s the same place that I got the ARM version from.

And here’s the result. A slightly sluggish (well it is under Hyper-V). I had to comment out the code that initialises the audio. Line 580 ish.

/*	int success=Mix_OpenAudio(22050, AUDIO_S16LSB, 2, 8192);
	if (success==-1 ) {
		LogError("InitSetup failed to init audio");
	}
	LoadSoundFiles();
*/

And here’s the results.

As a way of checking that the stuff I’m posting on GitHub, I’ve been downloading them onto a laptop and testing them.

The laptop is a seven year old Toshiba that was re-purposed from Windows to Ubuntu 18.04 LTS, the same version as I’m running in a Hyper-V session on my main development PC.

Although the laptop is older and only running an i3 chip, it still outperforms the game code running under Hyper-V code on my five year old i7-5930K PC.  I think the difference is purely because the GPU code is run in a software layer not on the real GPU. But I might be wrong.

When I tested it with 255 asteroids on screen the laptop still maintained 60 fps but the Hyper-V running version dropped below 60 fps once there were 125 asteroids on screen. I have a suspicion that C code that isn’t calling any SDL routines would run faster under Hyper-V because it’s virtualised.