Tag Archives: fedora

In Search of the Ultimate Desktop

Back in the day, when first started playing with Xen years and years ago, I had this idea of being able to run a multi-user desktop, with each user getting their own OS with a keyboard, mouse, and monitor all running from the same physical computer. I didn’t really have much use for it at the time, but I thought it would be a pretty cool demonstration of the technology. I discovered pretty quickly that it wasn’t possible. Hardware assisted virtualization (HVM) was around at that point, but Xen lacked the ability to pass a video device into the child OS.

The times have changed, as the following long-winded video demonstrates:

As of version 4.0, Xen now has the ability to pass a VGA device through to a child instance. This makes my idea possible, and now I have to try it!

A fair amount of research on the subject left me a bit disheartened. Said research told me that in order to pass a VGA device through to a fully-virtualized child instance (the only way you can run Windows in Xen), you need to have special hardware support that’s only found in newer machines. None of the machines I have, even the whole pile machines acquired in the hardware free-for-all at work, had the necessary hardware support. My goal was out of reach.

I still wanted to try it though, just for shits and giggles. Something told me it was possible. My reading said that it was possible to pass VGA adapters through to paravirtualized child OSs, and Windows has paravirtualized driver support via the GPLPV driver bundle. They’re not exactly the same, but I figured it was worth a try to see if things worked. I set up a test box running Fedora 16/Xen 4.1.2, and grabbed a templated Windows XP install to see if I could make things work.

I set up the Windows with the latest GPLPV drivers and configured the parent to pass through a PCI express slot containing a Nvidia GeForce 8400 GS to the child. I tried configuring the device as both the primary graphics adapter and a secondary one, but neither worked completely. With the card configured as a secondary adapter, I could still interact with the system via the Xen-provided VNC console. From there I saw that the card was being seen by the OS, but it wasn’t able to activate it. Unable to start device. Code 10. Blah. So close! The parent’s logs showed repeated issues with IRQs, so I’m wondering if something isn’t lining up properly that I can fix.

At one point, I was able to (accidentally) make the Windows instance use the crappy onboard video card the parent was using, so I’m hopeful! Xen’s documentation says that passing the parent’s VGA card to a child seems to be stable, but that’s not really what I’m going for.

In reading some of Xen’s wiki documentation, it seems that ATI graphics hardware might be better supported at this point. That fact hasn’t made things work any better. I tried a Radeon card to no avail. Nerds! Perhaps I just need to buy some new hardware to make this go.

Free Stuff and Kickstart Hell

Recently, my employer had a free hardware giveaway that allowed employees to pick through pallets upon pallets of retired server hardware and claim things as their own. Some of it was known to be dead, but the state of most of it was unknown, so it was kind of a crap shoot. I grabbed myself a few (okay, thirteen) machines in the hopes that I’d pick up a few decent pieces of machinery. As luck would have it, ten out of the thirteen boxes were in working order. Five of them were dual-dual core machines, and the other five were dual-quad-core machines, all server grade. After picking up some RAM, I have a pile of working machines just waiting for something to do. Time for a new lab setup at home!

The first thing I’m working on is a kickstart setup to automate system installs of various types. I’ve got a few basic CentOS server setups configured already, and I’ve been working on some Fedora-based stuff as well. Fedora is much more bleeding-edge, so there’s a lot of change from what I’m used to with the “OMG SO OLD” CentOS.

One of those differences cropped up while I was trying to write up a kickstart script for a Fedora 16-based desktop with an encrypted storage setup on a software RAID1. Prior to Fedora 16, one could easily set up a kickstart that would partition a disk with “growable” RAID partitions of non-fixed size – a partition on the disk that would grow to fill the available space on the disk. Fedora 16 forces you to create a RAID partition of fixed size, without the ability to fill up the available space. This makes the kickstart script non-flexible, since you have hard-coded size values for each partition. This is not at all desirable in the setup I was going for, except for the /boot partition.

With a bit of elbow grease and a non-trivial amount of time spent waiting for test runs to complete, I was able to craft a work-around. I’ve documented it here.