Cisco VIRL ESXi Installation Notes

629 Words. Plan about 2 minute(s) to read this.

Note: I was part of the early VIRL beta program. For my efforts in that beta, I was provided a free one year subscription to VIRL, worth $199.

I’ve got Cisco VIRL up and running on ESXi 5.5. The installation was mostly smooth, but there were some hurdles to overcome. Here are my installation notes while they are still fresh in my head.

  1. After purchasing VIRL, you have to wait to get a link where you can download VIRL. You need to have a CCO account to do this. The download link will be sent to the email in your CCO account, even if you placed the order via a different email.
  2. The OVA is 3.6GB, and downloaded slowly. To get the entire file took several hours. I don’t think I saw the download stream above 1Mbps, despite having far more bandwidth available. The download had to survive several network disconnects and reconnects. Google Chrome’s download manager handled this with aplomb.
  3. The license file for VIRL is downloaded via a separate link in the e-mail. Don’t overlook it.
  4. I followed the installation procedure here. The rest of my comments relate to steps in that procedure where something didn’t go as expected or I deviated from the instructions.
  5. In step 4, I chose thin provisioning instead of “Thick Provisioned Lazy Zeroed,” and thus far have had no issues.
  6. In step 6, I did choose to use static addressing instead of DHCP for the main VIRL management interface.
  7. In step 8, I had a lot of trouble with NTP synchronizing, but this is a key function required by VIRL for proper interaction with the Cisco “salt” servers that are a part of the licensing scheme. The issue I had was a huge offset and jitter that varied wildly in between my ntpq queries. This problem is not unique to VIRL. Rather, this is an issue running NTP in a virtualized environment. VMware KBase article 1006427 explains the problem and offers several workarounds. My process was to follow the “NTP Recommendations” and “VMware Tools time synchronization configuration” steps. In short, I updated the NTP configuration file and disabled syncing the VM time to the ESXi host time in the VMware Tools settings.
  8. In step 9, I was unable to launch User Workspace Management because the backend service was not running. I was able to bring it up manually at the console with “sudo service virl-uwm start”.
  9. In step 10, I neglected to set ‘using_dhcp_on_the_public_port’ to ‘False’ when I was supposed to. I have since noticed this and edited the /etc/virl.ini file. I’m not sure what negative effect this might have had on things, but everything seems to be working okay.
  10. In step 11, I got stuck at “3 – Install Changes” — just a blank terminal window with nothing happening. I believe the issue was due to a lack of network connectivity. Most likely in “1 – Install Networking”, the management interface has been reset to DHCP instead of static. To resolve this, I edited /etc/network/interfaces again, and changed it back from DHCP to static again, and rebooted the VIRL VM. After that, I was able to run “3 – Install Changes” with no problems. There’s a VIRL community thread about this here.
  11. In step 12, it did take a while for each agent “alive” status to become “:-)”, possibly a little longer than I expected because I had just rebooted the VM.

With all of that done, I was able to get the VM Maestro client installed and connected to the VIRL server. I was then able to launch the sample “2-node.virl” topology and have both nodes ping each other.

I’ll blog more about VIRL when I’ve had a chance to set up some topologies on my own and generate some configurations with AutoNetkit.

vm-maestro-screenshot



Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

Comments

  1. Matt Haedo

    The deployment was pretty straightforward but a bit more involved than I thought it would be. I was expecting to just deploy an OVA, not create another 5 VM port groups and corresponding VLANs.

    Also, I didn’t think the instructions were very clear in which VLANs should be routable and which were for VIRL internal use only, so I just created an SVI for each VLAN and made them all routable. Granted, I just skimmed the deployment guide. One of these days I’ll make the time to dig in.

    1. Post
      Author
      Ethan Banks

      I think the issue is that VIRL is deployed on top of OpenStack, and VIRL users have to create the underlying network for the vSwitches in OpenStack to talk to. Since this is a hypervisor-on-hypervisor deployment, it’s complex that way. Effectively, VIRL users have to create the virtual network on ESXi that for a “normal” OpenStack deployment would already exist in the form of the physical network.

      A bigger point to be made perhaps is that VIRL can’t be thought of as a GNS3 replacement. Different tools, different scale, different target audience (I believe).

      1. Mark Rakozy

        “A bigger point to be made perhaps is that VIRL can’t be thought of as a GNS3 replacement. Different tools, different scale, different target audience (I believe).”

        I fully agree. But then, Cisco should do a better job of positioning this. I was looking VIRL as a potential solution that would provide the flexibility of GNS3, but with a bit more reliability (spend more time modeling and testing networking, as opposed to troubleshooting GNS3). So far, I am disappointed by the complexity of VIRL… especially given the price I had to pay. Hopefully, my view will change as I spend more time with it.

  2. CR

    My biggest questions – is there any switch / switching support – which is the biggest limitation in Dynamips / GNS3 ? Also, how well does this run on a regular desktop / laptop ? I’m going to be trying this on a 2.3 GHz i7 MacBook with 16 GB of RAM using VMware Fusion. Either way, if I can get a 3 or 4 router topology running IOS 15 and IOS-XR,XE, NX-OS flavors without the flakiness of Dynamips, I’ll be satisfied.

Comments are closed.