Posts Tagged virtualisation

Sharing an OSA port in Layer 2 mode

I posted on my developerWorks blog about an experience I had sharing an OSA port in Layer 2 mode.  Thrilling stuff.  What’s more thrilling is the context of where I had my OSA-port-sharing experience: my large-scale Linux on System z cloning experiment.  One of these days I’ll get around to writing that up.

Tags: , , ,

Network virtualisation

I’ve been doing a lot of mucking around with KVM with libvirt (I keep promising an update here, don’t I).  In my desktop virtualisation requirements I had a need for presenting VLAN traffic to guests: simple enough, and I’ve done it before.  You can do what I usually do, and configure all your VLANs against the physical interface then create a bridge for each VLAN you want to present to a guest.  The guest then attaches to the bridge appropriate to the VLAN it wants access to, with no need to configure 8021q.

(The other method of combining VLAN-tagging and bridging is to bridge the physical interface first, then create VLANs on the bridge.  I couldn’t work out how to get VLAN-unaware guests attached to this kind of setup, and it didn’t work for me even to give IP access to the host using a br0.100 for example.  Still, it must work for someone as it’s written about a lot…)

I realised that from particular virtual machines I needed to get access to the VLAN tags — I needed VLAN-awareness.  Now I knew up-front that the way I could do this was to just throw another NIC into the machine and either dedicate it to the virtual guest or set up a bridge with VLAN tags intact.  I really wanted to exhaust all possible avenues to solve the problem without throwing hardware around (as I’ve been doing a bit of that recently, I have to admit).

First, I tried to use standard Linux bridges as a solution, but discovered that an interface can’t belong to more than one bridge at a time, which put paid to my plan to have one or more VLAN-untagging bridges and a VLAN-tagged bridge.  I figured it could be done with bridges, but I envisaged a stacked mess of bridge-to-tap-to-bridge-to-tap-to-guest connections and decided that wasn’t the way to go.

Next I checked out VDE, which I had first seen a couple of years ago — but something gave me the impression that VDE either wasn’t really going to give me anything more than bridging would, or was not flexible enough to do what I needed.  I like the distributed aspect of VDE (the D in the name) but I’d rarely use that capability so it wasn’t a big drawcard.  I widened my search, and found two interesting projects — one that eventually became my solution, and another that I think is quite incredible in its scope and capability.

First, the amazing one: ns-3, “a great network simulator for research and education”.  As the name suggests, it simulates networks.  It is completely programmable (in fact your network “scripts” are actually C++ code using the product’s libraries and functions) and can be used to accurately model the behaviour of a real network when faced with network traffic.  The project states that ns-3 models of real networks have produced libpcap traces that are almost indistinguishable from the traces of the real networks being modelled…  I’ll take their word for that, but when you get to configure the propogation delay between nodes in your simulated network it seems to me it’s pretty thorough.  Although the way that I found ns-3 was via a forum posting from someone who claimed to have used it to solve a similar situation as me, and ns-3 does provide a way to “bridge” between the simulated network and real networks, the simulation aspect of ns-3 seems to be more complexity than I’m looking for in this instance.  It does look like a fascinating tool however, and one I’ll definitely be keeping at least half-an-eye on.

To my eventual solution, then: Open vSwitch.  Designed with exactly my scenario in mind–network connection for virtualisation–it has at least two functions that make it ideal for me:

  • a Linux-bridging compatibility mode, allowing the brctl command to still function
  • IEEE 802.1Q VLAN support (innovatively at that)

The Open vSwitch capability can be built as a kernel module (there’s a second module that supports the brctl compatibility mode), or very recent versions have the ability to be run in user-space (with a corresponding performance drop).

On the surface, configuring an OvS bridge does seem to result in something that looks exactly like a brctl bridge (especially if you use brctl and the OvS bridging compatibility feature to configure it), but its native support for VLANs really brings it into its own for me.  In summary, for each “real” bridge you configure in OvS, you can configure a “fake” bridge that passes through packets for a single VLAN from the real bridge (the “parent” bridge).  This is exactly what I needed!

For the guest interfaces that needed full VLAN-awareness, I simply provided the name of my OvS bridge as the name of the bridge for libvirt to connect the guest to–OvS bridge-compatibility mode took care of the brctl commands issued in the background by libvirt.  The VLAN-unaware guest interfaces presented a bit of a challenge–the OvS “fake” bridge does not present itself like a Linux bridge, so it doesn’t work with libvirt’s bridge interface support.  This ended up being moderately easy to overcome as well, thanks to libvirt’s ability to set up an interface configured by an arbitrary script–I hacked the supplied /etc/qemu-ifup script and made a version that adds the tap interface created by libvirt to the OvS fake bridge.

The only thing I might want from this now is an ability for an OvS bridge to have visibility over a subset of the VLANs presented on the physical NIC.  The OvS website talks about extensive filtering capability though, so I’ve little doubt that the capability is there and I’m just yet to find it.  From a functionality aspect, OvS is packed to the gills with support for various open management protocols, including something called OpenFlow that I’d never heard of before (but I hope that some certain folks in upstate New York have!) but is apparently an open standard that enables secure centralised management of switches.

Detail of exactly how I pulled this all together will come in a page on this site; I’ll make a bunch of pages that describe all the mucky details of my KVM adventures and update this post with a link, so stay tuned!

Tags: , ,

The “Technology With The Worst Name Ever” Award

…and the winner is: KVM!  Why?  Because as you read this, some of you will be thinking I’m talking about a keyboard-video-mouse switch, while some of you will be thinking I’m talking about Linux kernel-based virtualisation (still others are probably thinking of something else… what I don’t know, but I reckon I can be sure that the letters KVM have not been put together only twice in human history).

For the record, I’m talking about Linux kernel-based virtualisation.  It wins my award for the Technology With The Worst Name Ever because if, like me, you go looking on your favourite search engine for issues with Linux kernel-based virtualisation, all you find is issues about keyboard-video-mouse switches.  This is because for the last fifteen years (at least), in the computer industry KVM has stood for keyboard-video-mouse (switch).

This is not your common-or-garden-variety case of acronym overloading, either, because many folk (myself included) still use a KVM.  Usually acronym overloading occurs when the acronym being overloaded has fallen from use and a new technology takes its place, or when an acronym is used to reference a little-known technology and a new usage of the acronym is unaware of the previous usage[1].

Here, KVM was already in heavy use, and I’m sure that none of the Linux kernel hackers could claim to being unaware of the term.  Yet they used it anyway.  And nothing in /usr/src/linux/Documentation explains why.

I’m sure there’ll be something out there about why they chose the name…  but in the meantime I’m left to find other reasons why KVM doesn’t seem to work on my system.  Which KVM do I mean?  Ah, that’s for me to know…  😉

[1] RTP is an excellent example of this — it was already in use as Rapid Transit Protocol (a part of the APPN-HPR suite), but the VoIP folk never heard of APPN and used RTP for their Realtime Transfer Protocol.

Tags: ,

Rebooting my belief system

I’ve been away from SHARE for far too long.  It’s really great to hear positive things about Linux on zSeries again, rather than the crap I have to put up with at home.

In Australia, there is no evangelism of zSeries.  There’s an attitude bordering on arrogance that seems to say “we’re not going to explain zSeries to you; if you don’t know you want it already then you’re not worth it”.  At least that’s what it looks like to me.

I’m surrounded by people who think that all problems can be solved by installing an xSeries or pSeries machine.  Maybe some can be, but IMHO they’ll be replacing one set of problems with another (possibly greater) set.

Anyway, it’s nice to hear different stories — like a company whose IT costs went from 1.7% to 0.9% of sales by migrating their ENTIRE server farm (including about a dozen p690s) to a z990 running Linux.  Like a company that has placed 250 Linux server guests onto z/VM inside a year, freezing acquisition of new discrete servers.

Tags: , ,