QEMU Network: QEMU Networking, HowTo Setup
by Mike Levin SEO & Datamaster, 07/29/2010
Note: If you want a ready-made tiny virtual Linux using QEMU that runs with a double-click from your Mac, Windows or Linux machine that’s set up with default QEMU networking and an SSH and HTTP port allowing in-bound communication from the host, then try my linux distribution, Levinux.
Okay Padawan, while I’m dying to put the finishing touches on the ability to easily double-click launch our pendrive virtual machine from either PC or Mac, there’s one more step that comes first that I neglected to show. It’s the last thing before you can consider the bare-bones install finished. And that’s configuring the network interface for DHCP.
But first, some education for the uninitiated. Setting up DHCP means getting your virtual machine on the Internet.
Background: Everyone using WiFi at home is using the DCHP service provided by your home WiFi router, whether you know it or not. This is how you get an Internet address assigned to your machine. Actually, you’re getting a private IP assigned to your machine. For most people’s setups, your Cable or DSL modem assigned the one true publicly addressable Internet IP to the AirPort, Linksys, Netgear or DLink WiFi router you plug into your broadband modem. Everything that connects to the Internet through your WiFi router gets a private IP that is actually not directly accessible from the Internet. The way your machine can reach the Internet then is a clever system by which OUTBOUND requests from your machine get routed out through your router (hence, the name router) and look as if they originated from one single public IP. The returning response is sent to that IP address, and your router is smart enough to… well… ROUTE the reply back to the machine that initiated the request, although it itself doesn’t have an Internet-accessible IP address.
Get it? Everyone has a private local area network (or LAN) in their house. This is necessary, because your Internet service provider is only going to issue you one publicly addressable IP, and getting all your other home devices onto the Internet is up to you. The DHCP service built into home WiFi routers is what does this. How can solid-state devices like WiFi routers be running a service so much like an expensive server computer? Did I mention that WiFi routers are themselves little Linux computers running on MIPS processors, which could themselves be converted into shankservers? But I digress.
Most corporate networks these days also use DHCP to get both desktop and laptops onto the network, because there is just so much administrative overhead to assigning a specific address, or IP, to each computer, and doing the reconfiguration work anytime anything changes. It’s much easier to set a computer up to automatically request and get issued a new IP every time it connects to the network. Many of us are familiar with how to do this under PC and Mac, but doing it on Linux is a matter of editing a single file, using those same vi skills we’ve been developing earlier in these tutorials.
The point is that DHCP servers are pervasive, and you can rely on them. So QEMU is going to get it’s private LAN IP from the corporate or WiFi DHCP server, right?
Well, not exactly. Although our configuration file will look absolutely identical to if it were working this way, the truth is that by default, QEMU sets up it’s own LAN that’s only shared by the host computer, and your QEMU virtual server. This “virtual LAN” or VLAN such as it is has ITS OWN DHCP server running on it, distinct and separate from the one on your real network that the host computer got it’s IP from.
The new QEMU DHCP service running on the VLAN issues an IP to both your host machine and to the virtual machine, making them able to communicate with each other, but nothing on the outside world is able to reach your virtual machine. This is a mixed blessing for a server. On the one hand, it’s a brilliant security model, because when you fire up your VM, there’s no ability from anyone from the outside able to notice the presence of a new machine with network software, and start attempting to probe it for vulnerabilities and hack it. On the other hand, it makes it challenging when you want to set up server-like services on your virtual machine, such as a Webserver or file sharing. We’ll deal with this later, and it won’t even be an issue on real hardware instances of your shankserver, because real hardware doesn’t have the same networking challenges as virtual servers.
So how does your virtual server reach the Internet at all? Easy! The same way as your home machines on your LAN. Any network requests created by your VM are routed by a virtual router built into QEMU out through the host machine, so all network traffic originating from your VM looks to the outside world exactly as if it originated from your host machine, so then continue its journey out through your actual hardware router, and about a dozen other routers like it throughout the Internet until it reaches the actual box addressed by your request. The response then makes the return trip, and when it hits your host machine, it routes it into QEMU and home to your virtual machine.
Easy, right? All that as education for a simple file edit. But trust me, you’re better-off knowing this that not, for when a snooty sysadmin notices you plugging your USB pendrive into your Mac or PC and firing up a virtual machine without so much as administrative rights to your own machine, and starts scolding you: “BAD USER! BAD USER!” Just casually explain to him that all you’ve done was run QEMU on your local machine, which creates a VLAN possessing its own DHCP service so that your Debain instance consumes no corporate IP–nor does it have any detectable footprint on the corporate network at all.
Yet, you’re still on the Internet–WOOT!
Trust me, following the path I’m setting before you, you are bound to go toe-to-toe with your system administrator eventually, and I probably shouldn’t really encourage you to do so yet, as you are probably not ready yet to resist the the dark side’s ability to choke you to death with the force. So just stick with me, and practice. You will eventually have great powers.
Speaking of great powers, if a shankserver is like a lightsaber, then vi is like working with Yoda. It can be very frustrating, but a lot like lifting an X-Wing fighter out of a swamp, there’s much heavy lifting you can do with this seemingly cryptic and inaccessible program. So, if you’re going to use vi, then do or do not…there is no try…
Log into your VM and type:
You will see:
This tells you that you are indeed in the right file, because although debootstrap doesn’t presume to put a default DHCP configuration in there, it at least does create the file. It’s pretty much the first thing you go in and touch after completing a Linux installation. So now, type:
[Down arrow] o auto eth0 iface eth0 inet dhcp [Esc] :wq
The moment before you hit Enter after :wq, it will look like this:
You should now be at the shell prompt. Instead of having you restart your virtual machine to get your network services started, I’m going to show you how to do it with a command, along with a before-and-after example to show you getting an IP. So, first type:
It should just come back with another prompt. You have no IP. Now, type:
You will see this:
You hardly have to do an “after” now, but if you want to, just type:
You will see that you have been issued the IP 10.0.2.15. This will be the same no matter what machine you fire up on. This is the IP that is always given to the first QEMU session, and is only known on your new VLAN shared between your VM and host, but which is completely unknowable to the outside world. Doubt me? Well, your host machine needs to have its own IP on your VLAN, and indeed it does. It gets 10.0.2.2, and you can confirm this by pinging it:
…but if you were to open a new DOS CMD window on your host PC, and type in ipconfig (the DOS equivalent of ifconfig), you can confirm that no such IP exists on your local machine, and any attempts to ping it will result in “Destination host unreachable”. Your QEMU virtual session, although it has access to the Internet itself, has disguised itself as your host machine as far as network traffic is concerned, and is completely unreachable, except in response to requests it itself has issued.
This is a permanent change. If you wish, you can issue the command to reboot your machine, and confirm you still have networking:
shutdown -r now
Once your machine has rebooted and you have logged in, a pretty nifty thing to do now is update your Debian repository of available software. This repository stored on your local machine to ensure that you can always get the latest version of any Debian-compatible software. This is a fixed list, and depending on what repositories you “subscribe to” determines what software is available to you with the apt-get command. The list of repositories you subscribe to is at /etc/apt/sources.list You can look at the list by typing:
Each repository you are subscribed to gets its own line in this file. You will see that you are only subscribed to the main Debian repository for the squeeze release. That means that you can only install software with apt-get that has been officially tested under this release. This is fine, and we’re going to keep it that way for now. It will let us get all the usual suspects, like Apache and Python. But there are some big repositories out there that open up whole new worlds of software, so just keep it in mind for later. Exit out of vi if you haven’t already, with :q
Now, update your system by typing:
If this works, you know that you set up your networking correctly. Sit back and relax, or go get a cup of coffee. This will take a few minutes. You’ll see a bunch of stuff scroll past you as it pulls down a copy of everything that’s happened in Debian squeeze-land since the Knoppix LiveCD you debootstrapped from was made. This can take awhile the first time, but then is much faster in subsequent updates. It’s also interesting that we did a “df -h” immediately prior to this. We will see how much room an apt-get update takes. Keep in mind that this only updates the local copy of what works with what, and not your software itself. That will be another command. Once the update is done, another df -h shows us that the update took very little room:
So now we are prepared to get any software that’s part of the main Debian repository, using similar apt-get commands as we used to do the update. In fact, installing software is hardly any more difficult than doing that update.
THIS is a good status for your harddisk.raw image. If you haven’t backed it up and tucked it away somewhere safe for instant “go-backs”, then do so now!