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

Could you explain some of the differences, and similarities between cloud computing and terminal server computing?

Credit where credit is due

Now that I've put this little post to bed, I wanted to thank Lew Pitcher, Fred Richards, and Harry Holt who offered support, advice, and let me use them as a sounding board for ideas while I was beating my head against this cross network KVM bridging issue [ insert appropriate smiley here ].

-- Marcel

The expanse of space surrounding Planet *buntu is getting busier and busier. As a result, achieving a stable orbit is particularly difficult when you're easily distracted. Consequently, Marcel Gagné's blog looks at pretty much anything and everything that orbits Planet *buntu. News, howtos, rumors, opinions, controversy, tech tips, helpful hints . . . you'll find it all here. Oh look! A shiny object!

Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30