Cloudy Days On Planet *buntu
I'd like to begin by apologizing for the complete lack of controversy in today's post. I appreciate your understanding in this difficult time when I am finding it hard to really get upset about anything. But I digress.
Pick up issue #2 of Ubuntu User magazine, open it to page 16, and you'll find an article titled "Cloud View" (by yours truly), the focus of which is Canonical's new offering, Ubuntu Enterprise Cloud. You'll find stories hyping this for the upcoming release of Karmic Koala (a mere 14 days away as I write this) but the framework, or a technical preview thereof, was available in Ubuntu 9.04. Canonical, the company behind Ubuntu, has partnered with Eucalyptus Systems, a company that has created an open source implementation of Amazin's EC2, or Elastic Cloud Services.
I mention this now for a couple of reasons. One is that I'm going to chat a little more about cloud computing. The second reason is that a lot has already changed since the release of my article in Ubuntu User #2. For one thing, I suggested that you could install the Ubuntu ec2 tool packages, or consider downloading the ones from Amazon. That is no longer true.
Download the appropriate euca2ools (Euca Tools . . . get it?) package for suitable for your distribution and install that instead. In the case of the Jaunty package, this consists of three different deb packages. You need to install all three. The next thing you need to know is that wherever I tell you about a command that starts with ec2, you should now substitute euca. For example:
ec2-describe-images becomes euca-describe-images
One additional plus here is that the tools have matured quite a bit since the technology preview. In the article, I mentioned that there wasn't much to the Web interface. I'm happy to report that it is maturing quite nicely.
Moving on . . .
More on KVM and networking.
When last I left this story, which does resonate somewhat with the whole cloud computing thing, I was desparately trying to get my virtual machine's networking set up in KVM on my new server. Here's a quick recap. Besides my primary IP address, I also have 7 additional addresses, on a different subnet than my primary interface, which I wanted to use for virtual machines (originally defined as eth0:1 through eth0:6) so that they could be accessible via the Internet. In effect, I want the VM to be a public machine with a public IP. I read dozens of online community documents, all of which left me scratching my head. I tried creating a bridge thing' but as soon as I did a 'brctl addif br0 eth0' as per the instructions, my system hung. How could I add this bridge if my machine is remote and I can't take down the interface to create it?
Well, I'll tell you.
The bridge interface is essential, and you really only have two choices in creating it. You can edit the /etc/network/interfaces file with the appropriate information, make absolutely sure you make no mistakes whatsoever (or you can't log back in remotely) and cross your fingers when you type 'shutdown -r now'. Alternatively, do what I did and get your hosting provider to hook up a KVM. That would be a Keyboard Video Mouse interface that essentially provides you with a physical console port. My hosting provider has Web-based KVMs which are rather handy when you need to reboot and there's a chance you can't get back on.
# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address eth0.ip.addr.ess
netmask 255.255.255.224
gateway eth0.ip.addr.ess
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
What you have here is br0 recreated with the same address settings as eth0. Your old eth0 looks pretty sparse in comparison.
As a next step, I created a new virtual machine using virt-manager. I'm not going to go through the whole process of creating a machine this way (at least not today) but it really is the easiest way. Just select Shared physical device.
If you spend as much time as I did researching this, you'll find plenty of documentation that tells you to set up a tap interface (e.g. tap0), which requires you loading the tun driver, then jumping through a pile of unnecessary hoops. It turns out that tap0 is a red herring if you use virt-manager (click on the thumbnail for a full-size snap).
By default, machines created with virt-manager to use bridging, create and attach their own tap device. No nee to create it. It's called vnet0 (or 1 or 2, etc). And it knows enough to add that interface to br0.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.003048d42980 no eth0
vnet0
vnet1
pan0 8000.000000000000 no
virbr0 8000.000000000000 yes
So far so good. You continue your VM graphical installation as you normally would with any Ubuntu install, assign a fixed IP when asked, proper netmask, and default gateway. You are almost good to go. Almost. To recap, I have a set of secondary IP addresses on the host :
SECONDARY IP ADDRESS
Usable secondary addresses: num.num.num.89-94
Mask : 255.255.255.248
I found out that the default route for this subnet is num.num.num.89 so I configured my VM's eth0 to 70.38.74.90 and gave it the appropriate default
route. It still didn't work.
You see, the hosts main IP had a different default route, so no way to route directly to the virtual machine. So I created a secondary br0 address (call it br0:1) on the main non-virtual iron and gave it the address of the default gateway ( num.num.num.89 ), like
this.
ifconfig br0:1 num.num.num.89 netmask 255.255.255.248
Just like that, my VM was routing. I could ping, do updates, download packages, you name it! And yes, it's accessible from the Internet.
Hurrah!
Until next time . . .
Comments
cloud and terminal server computing
Tuesday October 20 2009 03:04:04 pm
Randal
Credit where credit is due
Saturday October 17 2009 01:11:38 am
Marcel Gagne