After the fun try yesterday of getting an Ubuntu guest running under UNetLab, I started to think what else could I try.
Given that it would appear that if it comes in an OVA file, UNetLab has a pretty good chance of running it, then we should (in theory) be able to run a very wide range of VMs.
So my attention turned to UCS.
Now, it’s pretty obvious that the UCS is a pretty big bit of kit. But there is a UCS emulator. Not sure what kind of connectivity it offers, but it might be fun to give it a go.
I started by downloading the UCS Platform Emulator from Cisco, you’ll need a Cisco login to do this, and I grabbed the latest version (3.0.2c), which comes in a handy ova file.
I created a new directory under /opt/unetlab/qemu/ called win-ucspe-3.0.2, and while I was at it, renamed the win-7 folder from yesterday to win-ubuntu – makes it easier to figure out what’s what.
It takes a while to download the ova from Cisco, seems a lot of people find the 800+Mb download very slow.
Once it is downloaded copy it over (using Filezilla or similar) to /tmp, extract it, use qemu-img convert, and copy it to the new folder. Then run fixpermissions again. The full steps are below:
[email protected]:~# cd /opt/unetlab/addons/qemu/ [email protected]:/opt/unetlab/addons/qemu# mv win-7 win-ubuntu [email protected]:/opt/unetlab/addons/qemu# mkdir win-ucspe-3.0.2 [email protected]:/opt/unetlab/addons/qemu# cd /root/ [email protected]:~# cd .. [email protected]:/# cd tmp/ [email protected]:/tmp# ls vmware-root [email protected]:/tmp# ls UCSPE_3.0.2cPE1.ova vmware-root [email protected]:/tmp# tar -xvf UCSPE_3.0.2cPE1.ova UCSPE_3.0.2cPE1.ovf UCSPE_3.0.2cPE1.mf UCSPE_3.0.2cPE1-disk1.vmdk [email protected]:/tmp# /opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 UCSPE_3.0.2cPE1-disk1.vmdk hda.qcow2 [email protected]:/tmp# ls hda.qcow2 UCSPE_3.0.2cPE1-disk1.vmdk UCSPE_3.0.2cPE1.mf UCSPE_3.0.2cPE1.ova UCSPE_3.0.2cPE1.ovf vmware-root [email protected]:/tmp# mv hda.qcow2 /opt/unetlab/addons/qemu/win-ucspe-3.0.2 [email protected]:/tmp# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions [email protected]:/tmp#
Now, we can add it as a node, and fire it up:
We can VNC to it as well!
We cant do much at the moment, so we need to edit the lab, to add a host with which we can manage the UCS, and a router, to provide DHCP services to the UCS emulator.
So let’s do that!
Router(config-if)#do sh run | s dhcp ip dhcp excluded-address 10.120.1.254 ip dhcp pool UCS network 10.120.1.0 255.255.255.0 default-router 10.120.1.254 Router(config-if)#do sh run int e0/1 Building configuration... Current configuration : 68 bytes ! interface Ethernet0/1 ip address 10.120.1.254 255.255.255.0 end Router(config-if)#do sh ip dhcp bind Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 10.120.1.1 5000.0001.0000 Jun 19 2015 12:13 PM Automatic Router(config-if)#
Great! Now if we restart networking on the UCS, we should see an IP address:
So far so good. Can we get to the UCS? Well, no. But I think its a configuration issue, rather than a problem with UNetLab.
So I added a few more interfaces (I think 3 will suffice) to the UCS VM, and had to shut down the node and start it again for them all to be picked up. It did, at least get rid of some of the warnings on the UCSPE.
Eventually I got a “Network configured” message, and things looked much better:
So, long story short – you need three interfaces on the UCS VM.
After a few minutes, once UCS had done its thing, we can access the GUI from the Ubuntu host:
Freaking awesome! It certainly might help someone studying their CCIE DC!
I love the new HTML interface as well!
So there you go, UNetLab will happily run Ubuntu and UCS (PE at least).
Catch you tomorrow, when I’ll try and get a working Windows VM on the system as well!