The Open Virtualisation Format
(Wikipedia page)
describes a standard packaging format for distributing virtual
machines, particularly virtual appliances. (OVF 1.1 was adopted
as an ANSI standard in
2010.)
The basic OVF package is a directory containing multiple files.
VMWare have an OVF tool
for working with OVF in a VMWare ESXi/Fusion/Workstation environment.
An .ova file (an Open Virtual
Appliance)
is effectively a tar archive of an OVF package, which is
easier to distribute.
As part of my continuing effort not to install Oracle VirtualBox, I found VMWare's description of importing Oracle VirtualBox virtual machines into VMWare Fusion, when attempting to deal with SDNCon's distribution of a MiniNet environment as an Oracle VirtualBox 1.3GB OVA file. (This bloated distribution format seems to be encouraged by MiniNet, even though MiniNet definitions are just small Python classes that use a small Python module, both much smaller than 1.3GB.)
Once the .ova file is created and downloaded, the normal .ova
import process into VMware
Fusion
is simple:
Launch VMWare Fusion
Choose File -> Import...
Click on the "Choose File..." button and locate the
.ovafile, then click on "Continue"Enter a Virtual Machine name and destination to store the virtual machine, then click on "Save"
In the case of the SDNCon MiniNet environment, the OVF specification conformance or virtual hardware compliance checks failed, and a dialogue was displayed offering to cancel, or retry with relaxed checks -- so I told it to try again with relaxed checks. It created an Ubuntu 64-bit VM, with 1GB of RAM, an 8GB hard drive, and Private-to-host networking. I chose to pre-generate a MAC address for that network interface, in order to get a stable IP from DHCP. It appears the VM tried to connect to a CD-ROM drive on my machine, which does not exist (zero-spindle laptop), so I told it to start the VM without that device. (Possibly that was the hardware compliance check that failed.)
That SDNCon Mininet environment is an Ubuntu 13.04 ("Raring Ringtail")
VM (with about 700 packages installed), which appears to have had
MiniNet's install-mininet-vm.sh run on it. The ~mininet/mininet
directory contains a git clone of the MiniNet GitHub
directory. Beyond that, there
is a ~mininet/RF.py MiniNet network class (using an external
controller with a hard coded IP), and a ~/mininet/simple_switch_13.py
Ryu application, and Ryu 3.11 installed under /usr/local somehow.
It does have Wireshark installed, but it is an old version (1.8.2),
apparently with an older OpenFlow dissector (I am not sure which one; there
are two in ~/mininet: ~/mininet/ofdissector is for
OF 1.1/1.2 and marked as deprecated, and the other, in ~minnet/of-dissector
seems to be from a year old version from
Bitbucket). The latest
Wireshark release -- 1.12 -- ships with a built in OpenFlow 1.3 dissector,
but that does not seem to be the one installed.
According to the SDNCon MiniNet release announcement it is intended to be compatible with the Vandervecken ISO (itself based on a still older version of Ubuntu Linux -- 12.04 LTS). Following my earlier notes on installing the Vandervecken image to a harddrive allowed me to adjust both virtual machines to have a compatible network environment so they would talk to each other.
I found that I had to explicitly specify a compatible dpid, viz:
s1 = net.addSwitch('s1', dpid='0000000000000099', cls=OVSKernelSwitch)
in my copy of RF.py before Vandervecken's controller would actually
route traffic, but otherwise it did seem to work. At least with the
Vandervecken controller from 2014-07-16 (the ISO image seems to
have changed since I last downloaded it; I'm unclear how it has changed).
Other than the MiniNet-created switch defaulting to OpenFlow 1.3, there does not appear to be much that is significantly different to the MiniNet environment I built myself, based on Ubuntu 14.04 LTS. And the MiniNet/Vandervecken hookup worked basically the same as I found previously.