So plan B was to set up port redirection from the host to the guest, e.g. so that ssh’ing to localhost port 2222 would redirect to the guest’s port 22.

After a quick google, some fiddling with iptables, and a glance at the libvirt Networking wiki page, I was still having no luck. Then it hit me – my guest was using user-mode networking, and rather than getting its DHCP-allocated IP from the libvirtd-launched dnsmasq instance on the host, was receiving a hardcoded allocation of 10.0.2.15 from the host which is on 10.0.2.2. This can be extremely puzzling at first, because no network commands run on the host (such as ifconfig, iptables, brctl, route) will reveal this magic address, yet the host is still accessible from the guest via it.

After a lot more googling, I stumbled across a technique for configuring host to guest port redirection on a running VM. This sounded very promising, but virt-manager refused to accept the magic Control-Alt-2 key combination to switch to QEMU monitor mode. It turns out that this is no accident. However, since libvirt 0.8.8, the QEMU monitor can be accessed via virsh.
Note that the --hmp option is required, otherwise the monitor expects the command in JSON format, so omitting it leads to errors like error: internal error cannot parse json ... lexical error: invalid char in json text.

The final hurdle was figuring out the correct monitor command. The host_net_redir command as mentioned in the above article is no longer recognized. Luckily the QEMU monitor interface helped me out here – I spotted an encouraging sounding command hostfwd_add:

# virsh qemu-monitor-command --hmp sles11 'help hostfwd_add'
hostfwd_add [vlan_id name] [tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport -- redirect TCP or UDP connections from host to guest (requires -net user)

and google confirmed that the latter had superceded the former.

So finally we have the complete solution:

# virsh qemu-monitor-command --hmp sles11 'hostfwd_add ::2222-:22'
# ssh -p 2222 localhost
Password:
Last login: Mon Jan 23 00:37:44 2012
linux-mnsh:~ #

Hooray!

UPDATE: just found another very simple solution – add a new NIC to the VM which doesn’t use user-mode networking. Then it will get a IP (on 192.168.100.0/24 by default) which is still NAT’d but also routable via virbr0 on the host, meaning no redirection is necessary; just ssh directly to the guest’s IP from the host. A minor disadvantage of this is that the guest won’t be directly reachable from outside the host, but that’s unlikely to be an issue in most scenarios.

Just over two years ago, I blogged about taking a leap of faith and turning down two great jobs because they didn’t involve doing something I was truly passionate about. It was a gamble, but even after two months I could tell it was going to pay off. Sure enough, two years later, I found myself with a wealth of new experience and knowledge which I’d had a ton of fun acquiring, plus a healthy boost to my CV and set of friends and connections within the industry.

Then the stars aligned again, and I found myself with another life-changing dilemma: take an even more awesome job than the one I was in, or quit IT altogether and face an indefinite period of zero income. Pretty obvious what to do, right? I quit.

If that sounds crazy, it’s because it probably was – definitely another leap into the unknown. But I’ll try to explain my decision. I’ve had a number of life-changing decisions to make over the years, and I’m gradually learning to trust my gut instincts in those moments, because they’re generally right. I think they work out well because they’re usually based on my need to keep doing things I love doing (or to put it another way, my pathetic lack of tolerance for things I don’t enjoy), rather than concerns about money and other tedious “real world” distractions.

But wait, I hear you ask – didn’t I just say I decided not to pursue an even more awesome job than the one I loved doing for the last two years? How could my instincts guide me away from that? There are two parts to the answer.

Firstly, I had a bit of luck recently which combined with existing savings and investments meant that I could afford not to work for a while. Secondly, I’ve had an itch for a long time to play more music, and it just wouldn’t go away. In fact it kept growing and growing, until (20 years later than would have been ideal) I identified it as a basic need that I’m stuck with for good. When I say “play more music”, I don’t mean the kind where you go off and play along with CDs in your bedroom every now and again, or join an amateur orchestra. That’s enough for some people, and I totally respect that – but for some reason (false pride, perhaps) I could never bear to think of myself as a hobbyist musician. For better or worse, I only ever enjoy playing music when I’m playing to the best of my ability, and experiencing real progress.

Unfortunately, in music as with many things in life, progress requires hard grind – the standard blood, sweat and tears formula. Jazz musicians call it “shedding” which is short for “woodshedding”, because the idea is you lock yourself in a woodshed for 6 months and practice non-stop. If a 15 year career in IT has taught me anything, it’s that you can’t develop your musicianship quickly alongside a full-time job outside music. So I quit. Or at least, I’m taking sabbatical. To be honest I have no idea what will happen. Maybe I’ll go back to IT full-time, maybe part-time, maybe never. Right now I’m just focusing on studying, practising, playing with other people … whatever I can do to improve.

I decided that I’m most interested in developing my non-classical skills, especially jazz but also various types of folk, pop, Indian, and whatever else takes my fancy. I’ve played (Western) classical music my whole life and had some of the most incredible experiences from it, but now I want to explore what can be done on the cello outside that – cello is such a versatile instrument and there’s a whole new sound world which is a mostly untrodden path at this point.

That’s all I have time for now, but I’ll blog again soon about the amazing experiences I’ve already had around the USA in the last two months – I have a whole ton of photos, audio and video, so watch this space!

  <profiles>
    <profile>
      <id>unix</id>
      <activation>
        <os>
          <family>unix</family>
        </os>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <executions>
              <execution>
                <id>set-run-file-perms</id>
                <phase>generate-resources</phase>
                <goals>
                  <goal>exec</goal>
                </goals>
                <configuration>
                  <executable>chmod</executable>
                  <arguments>
                    <argument>0755</argument>
                    <argument>${project.build.directory}/foo.sh</argument>
                  </arguments>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>

Dear god. 34 lines and a plug-in, just to change the permissions on a file in a platform-specific way??

I should add that the above was written by an extremely smart guy who is a top-notch programmer; no, I don’t think the author is at fault here. Even if there’s a more concise/portable way of achieving the same result in Maven (and there might well be – I admit I’m still a Maven newbie), there’s still the undeniable fact that XML is horrendously verbose, and any code written in it is by nature unnecessarily difficult to maintain. To this end I applaud the ongoing efforts supporting the use of YAML to implement the Maven POM.

It’s worth seeing what the above would look like if we wrote it in rake:

require 'pathname'

desc "Make binary executable"
task :chmod do
  File.new(Pathname.new(build_dir) + "foo.sh").chmod(0755)
end

I don’t think I need to make a case for which is more legible or maintainable. Oh, and the Ruby version is cross-platform.

To continue an anti-XML rant which has been made countless times already: what the ant and Maven people don’t seem to realise is that XML is not a real programming language and is therefore not expressive enough to deal with many cases that a build system needs. The clue’s in the name, guys! “M” is for “markup” not “Turing-complete“. That’s why every time you need to do something vaguely unusual for which there isn’t an ant taskdef or Maven plugin, you have to write hundreds of lines more Java/XML just to cope with that case. That’s why Maven needs so many damn plugins.

The accidental silver lining to this is that because it takes so much effort to accomplish simple tasks, Maven developers find themselves compelled to reuse and share plugins, and to be fair, Maven has some good ideas on how to do this, even if the implementation isn’t always the best. For example, the built-in plug-in repository management and plug-in dependency management seem to work nicely, but unfortunately for some reason it has a propensity to download plug-ins on most runs, far more frequently than any sensible caching layer should.

DSL issues aside, I’m not convinced by the fixed lifecycle philosophy behind Maven either. I wonder if it was borne out of frustration with the lack of proper dependency checking in ant.

That said, I do like how Maven encourages standardization of the build lifecycle and phase namespace thereof, since newcomers to a project immediately know some familiar entry points. But the same could be said of 99% of projects which use Make and use standard rule target names such as install and clean. And I suspect that many developers suffer when they try to shoe-horn their own project’s build requirements into Maven’s standard lifecycle.

My concern with this phased approach is that it is too linear.  The expectation is that a build process is a one-dimensional sequence of steps, and you get to choose your starting point but not much else.  This seems fundamentally wrong to me.  A build dependency tree is well understood to be a DAG, and any build system which doesn’t model this properly seems to me to be burying its head in the sand.  On the other hand, if it does model it properly, which includes implementing proper dependency resolution, the required build lifecycle should emerge naturally without having to dictate that generate-sources comes before compile which comes before test and so on.

I’ve had some ideas of what the ideal build system looks like, and how to get there from the conventional Java world. More on that soon.

# list all disabled repos
rypper -d

# list all enabled repos with autorefresh off
rypper -e -R

# list all repos which have anything to do with KDE
rypper -x kde

# list priority and URIs for all repos whose alias contains 'home:'
rypper -a home: l -pu

# enable autorefresh on all OpenSUSE Build Service repos
rypper -u download.opensuse.org -R mr -r

# remove all repos on external USB HDD mounted on /media/disk
rypper -u /media/disk rr

I only got one response so I assumed it wasn’t that useful to other people.

However here I am at BrainShare EMEA in Amsterdam surrounded by like-minded geeks, and in a fit of enthusiasm / procrastination, I have finally got round to learning how to build openSUSE Build Service packages, and so proudly (?) present my first OBS package release: the 1-click install version of rypper. Enjoy!

UPDATE 21 March 2011: based on feedback from SLE Product Management, I have submitted a formal request to have zypper extended to include this kind of functionality.

Four hours trying to figure out why the hell my changes to .java source files weren’t showing up in the compiled binaries, debugging an unholy mess of ant XML files, before I finally realised how badly ant’s dependency checking sucks … Then 5 minutes of googling for ‘ant sucks’ and I find two excellently written rants which confirm my discovery (you might need to consult google’s cache for the latter).

I shouldn’t have been surprised.  Anything which uses XML as a domain-specific language should have already set the alarm bells ringing, but my excitement at learning something new initially blotted out the dull headache caused by hacking in XML.  Bah!

• My team is amazing. Really – full of uber-smart, motivated, helpful guys supported by great management, great interface to the business, and very slick, well-oiled processes.
• This was a huge sideways move, so the learning curve has been a similar experience to last year when I started triathlons and had to learn to freestyle without drowning. I love learning new things, definitely feel like I am over the hardest part now, and am trying to contribute to the team effort with as close as I can get to the breakneck speed the other guys do.
• When you really love something, it sucks you in – sometimes too much. Last night I was up until 3am   I need to follow the advice Michael Meeks gave me when I asked him for tips on how to deal with being a full-time home-working geek:
  

  Sure – get up at the same time every day; and quit work roughly 9 hours later without fail.

  Then you stay sane

• It’s a more solitary lifestyle than my previous role, so I need to make more effort to get out and socialize in the evenings. Actually this could be a good thing because I used to occasionally use “work is quite social” as an excuse for not going out if I was tired.

For the last 3.5 years I’ve been working as a Solutions Architect for Novell, a job which has:

• trusted me with working from home, even before I’d proved myself,
• introduced me to some great colleagues and new friends (Novell is full of highly motivated and talented people),
• pushed me outside my comfort zone many times (and in case it’s not obvious, that is a very good thing), including forcing me to confront and completely overcome my phobia of public speaking,
• taught me a whole range of technical and “soft” skills,
• given me the opportunity to work on projects with some of the finest minds in the industry and stay at the cutting edge of technology,
• given me the opportunity to meet, learn from, and help countless client customers and partners, both existing and prospective,
• rewarded me for innovation (I co-filed two patents),
• taught me how to understand, and where possible sidestep people politics (although politics are inevitable in any large corporation, Novell is relatively free of it and even the CxOs at the top are very down-to-earth, approachable people)
• and probably many other things I missed.

Despite all that, a while ago I started feeling that I needed a fresh challenge. And the feeling wouldn’t go away – in fact it kept growing. I started thinking about what to do, and as often happens when you open your mind to possibilities, a very promising new opportunity presented itself to me out of the blue, in the form of a job at another company.

So we come back to the crazy thing. I interviewed for this job, found out that it was certainly challenging role, and had phenomenal opportunities for career growth and networking, got an offer, and after much stress and agonizing, turned it down.

Two weeks later, almost exactly the same thing happened with another company.

Especially in today’s economy, what the hell was I doing turning down two great job offers? Well, I was taking a gamble based on the possibility of being offered something new at Novell which sounded more exciting than either of those.

Let’s back up again, this time much further. When I was about 8, I first discovered computers and quickly realised that they presented a whole new world where you could invent all kinds of wonderful new creations and you were pretty much limited only by your imagination. Well, this was quite a long time ago, so admittedly having only 1 kilobyte of memory and a cassette tape recorder which only worked once every 10 times for storing your programs on was a bit of a limit too, but hopefully you get the point. I realised that I liked making stuff.

This passion has stayed with me my whole life – it sort of went into hibernation for two amazing years at music college, although even then you could argue I was making stuff (i.e. music). And it’s why I turned down both those two jobs – even though they were great, they didn’t present immediate chances to create, and my instinct was telling me that’s what I needed.

So the great news I received earlier today is that the gamble paid off, and I have been formally offered a job as a Software Engineer Consultant, joining an extremely talented team based mainly in Santa Cruz in California. This is getting scarily close to being a dream job! I remember years ago voluntarily pulling 100 hour weeks at guideguide despite terrible pay, simply because I loved it so much – and I think this will give me the same kind of rush

For those wondering whether I’ll be relocating to California: for now, I’ll still be officially working from home here in London, but I’m crossing fingers for a business trip across the pond to meet the new team soon I hear it’s a beautiful stretch of coastline, and would be triathlon training heaven …