Friday, September 11, 2009

Console and Virtual machines

I know I may occasionally come off a bit hard-core in favor of the the text-mode and console environments, but, at the moment, there's something impacted beyond my preference of interface.

I've been working a lot with virtual machine setups over the last couple years. Rosetta Code has been running on VPS accounts under Xen (first at Slicehost, now at Linode) for quite some time, and then there's the various things I've done at work using various versions of VMWare.

VMWare is interesting, though. In a graphical OS such as Windows or Linux, it supports forcing the guests's virtual display to conform to VMWare's available view area; That's rather nice, as it means you're not stuck looking at a postage stamp on a huge monitor, or scrolling around a huge virtual display when you've got to look at it through a postage stamp. (Unity and Fusion are awesome and something else, but that's another tangent.)

Unfortunately, there are times and setups where you cannot have the overhead of a full GUI system. Linux being what it is, having the history it has, and the community origins it did, supports text-only environments. Additionally, Linux/UNIX console tools, coming from the roots they do, support resizing the display of text-only applications. Try resizing an xterm or PuTTY window, for example; The number of rows and columns change with the size of the window--you're not stuck in 80x24 or 132x24 land. (Yes, this sort of thing depends on termcap support, but that's not important at the moment.)

Unfortunately, unlike the with GUI goodness of X, VMWare can't resize the guest OS console to scale the same way. Sure, I can set up OpenSSH, connect in with PuTTY and get that same behavior, but what if I'm tweaking iptables chains? Fat lot of fun it is disconnecting oneself.

Oddly enough, Xen seems to have a similar problem. With both Linode and Slicehost, you get an AJAXy "console" much like you get if you run Linux without a GUI on an actual PC. Unfortunately, while my browser window might have a client area of 1680x1050, and the console font might only take 8x16 pixels per character, I'm not going to get a console environment of 210x65, no matter how nice such a large console might be.

Yes, I understand there's a variety of obstacles to the kernel framebuffer supporting dynamically changing display sizes. At the top of the list: Kernel programming is non-trivial. Yeah, I understand that. I occasionally watch lkml and read up on various subsystems for amusement, need and curiosity. Sure, there are framebuffer apps that assume that once the framebuffer size is set, it 's fixed. Oddly enough, GUI environments (even under X) did the same thing at one time, and some still do. That guest resizing deal only really works well with specific window managers; Some of my personal favorites are left out in the cold.

I'm not demanding anything; I can live with annoyances as I always have. But I'd like to put the bug in folks' ears and have them think about this sort of things...

No comments:

Post a Comment