Day 3 - Integrating GNS3 and the VMWare environment

Introduction

It's been a couple weeks, I've been busy getting ready to separate from the Air Force. But I'm on terminal leave now, and I've got nothing but free time!

What's Next

I've never been great at focusing on one thing at a time. Especially in the last couple months, when I've been at work and not able to access my VM environment, so I was just reading e-books on certifications. Unfortunately, with no access to a test environment, I can only read so much about a single topic with no hands-on practice before I have to switch tracks and read about something else.

With that in mind, I ended up switching tracks for a little bit to read my CCNA study material.

As with other certification projects, CCNA is hard to train for without a lab environment. GNS3 - the network simulator I mentioned earlier on - can provide that environment. But, I didn't want to branch off into a completely separate project. So I found myself wondering... can I integrate my current virtual environment with GNS3?

As it turns out... I can.

Getting Started

GNS3 basics

As a reminder, GNS3 is a simulator capable of running Cisco IOS images as virtual machines - except in this case, the "VMs" are network devices rather than traditional computers. (I'm going to call them VNDs just to avoid confusion.

I already installed GNS3 using pretty much all the default options (minus the numerous pleas to install Solarwinds stuff.)

When you first start GNS3, you have to configure it.

GNS3 offers a few different ways you can run VNDs:

1. The first option entails running a custom GNS3 Linux VM on your local machine, and your VNDs will run inside of that.
2. The second option is to have no GNS3 VM, and run your VNDs directly on your host operating system. According to my research, Windows has problems with emulating certain VNDs, which is why option 2 limits the types of VNDs you can run.
3. The last option is to connect to a remote GNS3 server, which hosts all your VNDs.

I'm already virtualizing everything, and I like functionality, so I went with option 1.

On the next screen, I went with the default options for the GNS3 server.

Next, assuming you went with option 1, GNS3 asks how you want to run the GNS3 VM.

You have two virtualization software options: VMWare, and VirtualBox.

As far as free stuff goes, you have a couple options: VirtualBox is free, as is the slimmed-down version of VMWare called VMWare Player. As you might expect, though, free comes with a couple drawbacks - VirtualBox doesn't support nested virtualization, which means it may run VNDs slowly. VMWare, being a free edition, doesn't let you do some really helpful things (like run multiple VMs at once.) If you're not planning on running any other VMs, though, VMWare Player should work fine for running the GNS3 VM by itself.

Anyways. I have VMWare Workstation, so I went with that one.

The neat thing about VMWare is that it has an interface for external software - like GNS3 - to integrate with it. So once you download the pre-built GNS3 VM from GNS3's website, all you have to do is double-click it, and it'll automatically import itself into VMWare, and GNS3 will be able to see it and interact with it.

I already did this, which is why "GNS3 VM" is already selected. I left the vCPU and RAM size alone, and finished configuration.

Starting GNS3

After you finish setup, GNS3 with automatically start its VM within VMWare.

At this point, I hit a snag, in the form of this dialog box, which kept going up to 100% and then resetting:

Progress bars have percentages for a reason - why do so many software companies defeat the purpose of a progress bar by filling it with false information? But I digress.

Meanwhile, over in my GNS3 VM, I had this worrisome message:

It appeared that GNS3 was trying to connect to its VM, but its VM for some reason was not connected to my home network.

As suggested, I went into the Networking configuration screen in the VM, and was warned that the server would reboot at the end of the process. Okay, sure.

Of course this couldn't just be simple. Oh well, at least I get to use nano instead of vi.

Okay. The file specifies that eth0 is the "host only" interface, and it appears to be set to use DHCP.

"Host only" is a type of VMWare virtual network interface which essentially creates a private LAN between a VM (or several VMs) and its host machine. VMWare should run a DHCP server on this private LAN to assign IPs to any VMs that ask for one.

In this case, however, it appears that this isn't happening.

Next step was to check that the VM itself was configured correctly:

As far as I know, the order that the adapters appear in the VM settings is the same order that they'll appear to the host machine (eth0, eth1, etc.) - so eth0 is in a host-only network as it should be.

As promised, once I closed out of nano, the VM rebooted. Fine.

Once it came back up, I got the same message.

This time, I decided to pull up a shell from the menu and see if I could figure something out from there.

`ifconfig | less`

Okay. Definitely not getting an IP address. Time to dig through log files... GNS3 keeps the ones I'm interested in in /var/log/upstart. In particular, I'm interested in network-interface-eth0.log - which had some helpful information at the end:

For whatever reason, VMWare appeared not to be responding to DHCP requests from the VM.

VMWare runs a service on the host machine called - imaginatively - "VMware DHCP Service." I'd had issues with VMWare services on the host machine before, so I restarted the service to see if that helped, then restarted the VM itself.

It didn't.

I did some more digging, and discovered an annoying quirk of VMWare's virtual network feature:

VMWare has two virtual networks named VMnet0 and VMnet1. They cannot be deleted or renamed.

As it turns out, VMnet0 is the default virtual network for VMs where a "bridged" connection (VM connected directly to the external network) is selected, and VMnet1 is the default virtual network for VMs where a host-only connection is selected. This isn't noted anywhere in the virtual network editor.

What had happened was, I got tired of trying to remember which VMnet was which (remember, they can't be renamed) so I just set them both to host-only, disabled DHCP, and created additional virtual networks that I COULD rename.

Except, now, my GNS3 VM was trying to use VMnet1 by default, which was a "dead" network with DHCP disabled.

So at this point, I deleted my custom network, reset VMnet0 and VMnet1 to their original settings, and rebooted the GNS3 VM.

Finally.

I went back to GNS3, and tried to finish configuration again... shocking, it immediately connected to the VM and asked me what I wanted to do first:

What's Next

Next, I need to create VND "templates" and add my VMs to GNS3. That falls under "customization," so it's going to be the next entry.