There is a small but vocal community in IBM who (with the companies support) use Linux as their primary computing environment. It’s not a particularly easy path to follow, because although office productivity tooling under Linux is actually very good indeed, the ability to interoperate with Microsoft’s proprietary “Office” products is still a major limiting factor. Since the use of Office is pretty much universal in business, you need to either avoid that interoperability issue, or find a way to overcome it.
The open source community have been working hard to make this easier, and LibreOffice in particular can now do things that only 5 years ago would have seemed impossible. For many of my colleagues who are in more technically focused roles, where the need for perfect interoperability with Office is less of an issue, this gives a “good enough” solution. But for some of us, who are in more customer-focused roles, it’s still a problem.
IBM helps us by providing a pre-packaged virtual copy of Windows that we can run under Linux, onto which we can add the MS Office suite if our roles require it. Probably 95% of the time, LibreOffice running natively under Linux is good enough for me. But if it isn’t I can always fire up the real thing, without worrying about all the instability issues of running native Windows. Did I mention my laptop’s uptime is a shade over 62 days at the moment?!
Unfortunately, Windows XP (that I run Office on) has nearly reached its absolutely final, never to be extended again, end of support date. So I need to move up to Windows 7. This has advantages and disadvantages for me; it has better functionality, better application support, and proper support from Microsoft. But at the cost of being much more resource-hungry. Although IBM has been pressing us to upgrade for some time, I’ve been holding out to avoid the pain.
Pain? Well, most people in IBM use KVM/QEMU as their hypervisor, and so IBM packages our centrally licensed copies of Windows into qcow2 images. But for mostly historical reasons I’m running VirtualBox on my Ubuntu-based system, and whilst changing to KVM wouldn’t really be a problem, I like some of the management facilities (such as snapshots) that VirtualBox provides. And VirtualBox doesn’t support qcow2 images.
So it’s necessary to do some converting:
- First, install qemu-img:
sudo apt-get install qemu-utils
- Next, convert the image:
qemu-img convert -f qcow2 -O vdi
Unfortunately, this expands the VM size considerably, as it doesn’t preserve the sparseness of the original qcow2 format. It looks like it could be possible to do a two step conversion (qcow2 -> raw -> vdi) using a mix of qemu and VirtualBox tooling to preserve that, but I wasn’t sufficiently concerned to investigate further. Storage really is cheap these days.
And at this point I can run my IBM-supplied Windows 7 VM under VirtualBox.
But I also discovered a couple of interesting things while I was doing this.
- Firstly, to my surprise it’s possible to mount vdi or vdh images so Linux can read and write directly to them. This is achieved by way of the FUSE filesystem, and a plugin called vbfuse. This used to be packaged for Ubuntu as “virtualbox-fuse”, but at the moment installing it takes a bit of hacking. Once installed however, it works beautifully, and allows direct access to the filesystems of (obviously stopped!) virtual machines.
- Secondly, I discovered that there is a Linux command line tool called “chntpw” that lets you alter the Windows password database directly. Using this it is possible to promote normal users to administrators, and reset or set their passwords.
Together, these allow you to reset any forgotten password within a VM, which can be most useful if like me, you rarely use it, and are forced to regularly change your passwords with non-trivial complexity requirements. More information can be found here, and the code itself is in the standard Ubuntu repositories.
Working in a sales environment I’m yet to find an alternative to the 40MB pivot tables from Excel. I suspect my windows PC has been up for 62 days. The fan and hard drive do fry every couple of years due to coming out of hibernation/standby in my bag. Not sure if its the OS or BIOS doing that.
I think that’s what I said. Amazed to hear that you’ve managed to keep a copy of desktop Windows up and running on a laptop for 62 days without a reboot though. I never made it to the end of the week (and often not even to the end of the day!) though admittedly that was with XP.
I think the starting up in a bag problem is where the machine gets knocked hard enough for a key to move, triggering the resume. So technically it’s the hardware, triggering the BIOS, that wakes the OS, that then slowly cooks the machine 🙂