I decided to have a little fun today, to see if UNetLab could run an Ubuntu node. UNetLab can run a Windows guest, courtesy of Qemu, so, in theory, another Qemu image should be ok, right? Linux hosts are not on Andrea’s (impressive) list of supported systems, but it’s worth a shot. So let’s see!I am starting with an Ubuntu VM in VirtualBox, a very minimal default install, just adding VLC and downloading a video from archive.org. The idea being that if two nodes can run, maybe I can multicast from one to the other.
Building the base image is no big task if you have ever created a VM in VirtualBox, so we’ll skip over that bit. I ran the updates, and shut down the VM.
Step 1 – Converting VirtualBox image to RAW
Because we cannot use the default VM filetype, we have to first convert the VDI file to a RAW image. To do that we use the VBoxManage command. The command is “vboxmanage clonehd old.vdi new.img –format RAW”, where old.vdi is he existing VirtualBox disk, and new.img is our RAW file:
C:UserssfordhamVirtualBox VMsUbuntu>"c:Program FilesOracleVirtualBoxvboxmanage" clonehd NewVirtualDisk1.vdi ubuntu.img --format RAW
You will see a percentage line below (if you have entered the command correctly), and once it hits 100%, which can take a while depending on the size of the VDI, and your processor, we can then move on to creating a image suitable for UNetLab.
Step 2 – Converting RAW to qcow
Once we have a converted (RAW) file, we can convert it to qcow.
To do this we need to install Qemu. I am using a Windows build from Stefan Weil, I got this from Qemu.org. Qemu comes with a command line program called qemu-img, and we can use this to convert to qcow (qcow2 to be exact). The command is “qemu-img convert -O qcow2 -f raw new.img newfile.qcow2”:
C:UserssfordhamVirtualBox VMsUbuntu>"c:Program Filesqemuqemu-img.exe" convert -O qcow2 -f raw ubuntu.img hda.qcow2
We don’t get a progress percentage with this command, so just sit back and wait a while. This is already installed in UNetLab – so you can also copy the img file created in step 1, and run the command on the UNetlab box itself.
Once we have our new file we can copy it over (using Filezilla). I am copying it to a new directory, called “win-7”, under /opt/unetlab/addons/qemu:
[email protected]:/opt/unetlab/addons/qemu/win-7# ls hda.qcow2 [email protected]:/opt/unetlab/addons/qemu/win-7#
Once we have run the fixpermissions script (/opt/unetlab/wrappers/unl_wrapper -a fixpermissions) – it shows up:
The node, however, would not start. I think this is due to VirtualBox though. So I am switching to VMWare player. Hopefully I’ll have better luck. If not it’ll be VMWare Fusion on my Mac.
Note, much time later, it turns out that VMWare player does not like OVF version 0.9, or 2.0 – it does seem happier with version 1.0 though.
So, using the same UNetLab vm, now (finally, grrr) exported into VMWare player, let’s see if it’ll run…
OK, third time is a charm!
I can now run an Ubuntu Qemu guest!
Not much of a network at the moment. So let’d make something a little better:
They all start:
But at this stage they do not communicate. I assigned both hosts to vlan 100, gave Win an IP of 192.168.1.101, Win2 an IP of 192.168.1.102. Created VLAN 100 on the switch, along with a VIF (192.168.1.1 wich was set as the hosts default gateway) – but nothing would communicate.
So I created this instead:
Note that R2 wont start at the moment. But really, this is not massively important right now. I just want to get the bare-bones working.
And, it does – though I have had to play around with the IP addressing (for obvious reasons):
We can ping from Win-2 (Ubuntu) to an IOL router (R4), we can also telnet to the router. So, we are off to a good start. Not sure why the other router would not start, but I do know that the laptop I am running this on is pretty underpowered. Hopefully I’ll have better luck on my Mac on Friday, when I create a Windows host, and if all goes well, will be able to connect it to the Ubuntu box I just created.
See you on Friday.