Networking the cloud (Part 1 of 3)

This is the first in three posts looking at networking in the cloud. This post looks at some basic concepts. Read part 2 of this series.


To understand how virtual machines are networked, let’s have a look at a notebook computer. On the side there is (probably) a socket into which you can plug a cable, the other end connecting out to the Internet. This is usually what is called an “Ethernet port.” Inside the notebook are some connectors from the computer’s mother board into the Ethernet port, where the processor at the heart of the machine can “talk” to the Ethernet port.

Now you may recall plugging in a new device into a notebook computer and seeing messages about “hardware drivers being installed.” A hardware driver is a special program that control things like these Ethernet ports. So the operating system running the computer will recognize that some data needs to be sent over the port and invokes a command to do this. This command is translated by the operating system to the specific command required by the Ethernet port.

As Ethernet ports come from different manufacturers, each type of port requires different specific commands to make all of this happen. This is where the hardware driver comes in: it can translate the generic command from the operating system into something specific for the installed hardware.

Virtual machines (VMs) calling out

In the virtual world, things get a bit tricky. After all, if a virtual machine is virtual then how can you plug a cable into it so it can communicate?

The answer is that you cannot. Remember that a virtual machine lives within the cloud, which in turn runs on a physical computer – a big server. Now that physical computer can be connected to a network. What the clever people in cloud laboratories did was to create virtual networking techniques and invented “virtual device drivers.” Yes, they created things like virtual Ethernet devices, which in reality are nothing more than programs within the hypervisor.

So if a VM wants to send some data to the Internet, it will have a virtual Ethernet device defined to it: a device which it automatically installed a driver for, just like in the real world. The fact that the device does not exist is irrelevant – the VM operating system is none the wiser.

As before on the physical world example, the operating system can work out which command to send to the virtual device to request some data to be sent, using the right driver. The hypervisor monitors this virtual device and cleverly translates that command to a “real world” command on a physical cable link. Thus your virtual machine can communicate with the physical world.

And incidentally, virtual devices are not restricted to networking: in order to see the output from a virtual machine, there will be a virtual display and keyboard too. Anything (pretty much) can be virtualized in this way, even disc storage.

Yes, but at which address?

Everyone understands that to access a webpage — say — you simply type “” into the top of a browser and the information appears. Actually, the Internet cannot understand this address as it works with numbers, not meaningful words. Behind the scenes is a special computer on the Internet called a “DNS Server” that translates your typed web address into an address the Internet can understand: something like “” This is called an “IP address” – in fact, you can type that into your browser and still access the BBC News. By the way, IP addresses are unique – hence why the world is running out of Internet addresses and why a new addressing scheme is being bought in, called “IPv6”.

So when you create a virtual machine (VM), it too must have an IP address. When the cloud Management Software creates the VM, the workflow has a pool of pre-defined IP address available to it which is accessed to ensure your new VM has a unique IP address. The network outside of the physical cloud infrastructure is set up to know that IP addresses in that range will be inside the cloud. The hypervisor knows which VM has which IP address and routes the message accordingly. Thus requests for data from outside of the cloud can find their way into the cloud – and out again.

Read part 2 of this series next.

Share this post:

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Archive Stories

OpenStack guest CPU topology configuration: Part two

In my previous post, I introduced the guest CPU topology configuration feature developed for the Juno release of OpenStack. As a reminder, the specification for this feature can be read here. This feature allows administrators and users to specify the CPU topology configured for an OpenStack virtual machine (VM). Initially, this is targeted to libvirt […]

Continue reading

Cloud 101: the definitions, the benefits, the ubiquitous

All these terms and more detailed definitions can be found on the National Institute of Standards and Technology website: The old concept (IBM® Mainframe) is back with a new name, new vision, and new infrastructure: cloud. Well, not new, still in its infancy, but exponentially growing. So, what is this cloud and how are […]

Continue reading

SaaS and cloud scaling basics: A perfect match

The basic concept of software as a service (SaaS) is like a utility approach—here's how.

Continue reading