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 www.bbc.co.uk — you simply type “bbc.co.uk” 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 “188.8.131.52.” 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.