There is currently 1 person online.

fedora 8 inst w/ xp virt

over the holiday i messed around extensively with fedora 8 and virtualization, and am jotting down some notes and discussion points for future reference. i recognize i have a bias towards intel (vs. amd) and nvidia (vs. ati), and while i feel i have good reason for that, i'm not justifying it here.

the attraction to fedora is somewhat easily explained, i love the power of remote computing, which unix has embraced in it's core since the dinosaurs first got online, the almost unlimited power and near infinite customizability.

virtualization doesn't just sound cool, but it opens up a boatload of potential to utilize multiple platforms simultaneously. i'm trying to phase myself away from windows, making a gradual shift towards an entirely legitimate (no pirated software) setup; but as a web developer, i've grown accustomed to certain standards of efficiency, some of which just don't have open-source alternatives.

open-source vs. shareware and commercial software

i have no issues with purchasing shareware per se, but in my experience open-source is generally better, since it lays it all out in the open, exposing the entirety to the scrutinizing public at large, and effectively enlisting in the development effort anyone who cares to spend a few moments with it. also i reckon making a financial donation to an open-source project is far more beneficial to the community as a whole, granting additional resources to a charity-like effort. this is leaps and bounds better (imo) than buying software that is considered (for the most part) complete, where your money is funding the developer's vacation, bugfixes and updates are scarce and left up to a much smaller team of developers, and major new features and improvements aren't ultimately meant to bring the enduser enhanced efficiency, but rather bring out their wallet and purchase the same product, repeatedly. granted this is a somewhat bleak view of paid software; commercial and to a slightly lesser extent shareware, but i think in short it sums up my view of the matter. i really could go on about this, and have (deleted much), but it's all tangential.

atm, i have need for both
i use machines for the following geekery: web development, games and video, serving, surfing, and of course communication. in terms of pc-games, well that's that; u need windows, and for the best in-game fx u need vista. u can't virtualize this at this time without suffering a noticeable performance loss, and if ur the least bit serious about ur gaming u're going to make a sincere effort to get the absolute most performance out of ur rig. for everything short of this however, web dev included, virtualization means ur not stuck in windows land if u want to use the windows tools.

"but what about mac!" u might aks; well hush up cuz they're far too expensive both financially and emotionaly for a disposable computer. u develop a sentimental appreciation of ur machine, and the apple community instills this far more than the windows pc, so when ur mac is not upgradeable u'll have a much harder time tossing it, not to mention macs aren't as component-ized so ur next mac will be a full machines expense, compared to the assortment of pc components that can be carried over in an overhaul, or individually replaced/upgraded. macs make up for this with their aesthetic style, but fuqit it i'm not so into the whole "institutional-safety plasticized-metal" look.

virtualization means u can have ur linux floppy windows, 3d desktop, terminal and compiler, and onna them floppy windows happens to be a full-on windows environment. ya sure it's basically virtual-pc, but ur domain0, or ur abstract/macro os is linux, so while ur doing ur windows stuff, ur doing it within an open-source os, so there's no point where ur ambitions are restrained by a companys decision to disallow progress.

i have just conducted encyclopedic volumes of research in getting xp and fedora on the same computer, and have had plenty of progress dialog boxes to ponder the benefits of the various approaches. i'm not about to exhaustively compare them, but i will offer the following transcript of my intentions and a few considerations..

i started off wanting to have a dual-bootable linux/windows setup, wherein i could select either at startup, and when running linux, the very same windows instance could be virtualized within linux; meaning i'd have access to the same win32 programs and settings whether i naturally booted xp, or i floppy windowed the virt. of course the graphics acceleration would be reduced in virt, but that's why it could be naturally xp booted; for pc-games or intensive photoshop work. this is ideal, but by my calculations unattainable at this time; one or the other os will conclusively have to exist in duplicate.

in the ideal approach, the xen kernel is being used, since it can provide the lowest level of control for a hypervisor to manage a guest os' interaction with the physical hardware, and assuming the processor in discussion supports the recent VT (vanderpool; or whatever the amd equivalent is) virtualization instructions, the guest os would observe an extremely minimal overhead performance load. ba-da-boom. err, almost.

the nvidia drivers for linux graphics acceleration were not found to be compatible or compilable with the fc8 xen kernel. i did see references and even how-tos relating to the fc6 xen kernel and nvidia drivers, so in light of fc8 having been released in the past month, it is likely a matter of time before nvidia drivers are repo'd that work with fc8 x86_64 xen. yes we're assuming a 64bit host os since the processors that support VT also support 64bit, and i hafta believe that a 64bit domain0 is largely responsible for the 'minimal' aspect in the notion of 'minimal overhead performance load'.

right, so if u can't get graphics acceleration in the linux host, then u hafta run a non-xen linux guest os to be able to use the nvidia drivers. that means u turn on the machine, fc8xen64 boots as a hypervisor, and proceeds to sub-virt-boot winxp and (non-xen) fc8_64. having 2 fc8 instances isn't the end of the world, but would require it's own effort of minimizing it's processes; being the non-graphics accelerated xen instance of linux, u could avoid a gui altogether, and kill off a whole 'host' of services, but this is signing up for a degree of research i am only speculating about. add to this stripping of services the realm of xorg device and screen mapping, and well, i have conceded with another approach.

en route to the way things are presently, i explored the software virtualization that parallels the hardware VT dependency. in fedora it's xen virt without the xen kernel. from what i gather the sacrifices of software virt is that there is more environmental emulation; some of the enhanced processor instructions are utilized, but it's not as close to a natural environment as hardware VT. from the start it negates the possibility for pc gaming since it's something, anything short of a natural boot.

yet this still almost delivered the ideal (in terms of the same xp instance virt or natural), except the way the fedora virt manager presents the guest with it's "drives", it can map an iso disc image as a virtual device for the guest (which would require significant effort to figure out how to grub/natural boot into an xp iso), or it can use a specific partition; but it presents the partition to the guest as a complete device, so (as i've tried) if you install xp en virt, nevermind the thought that it will see processor and video devices slightly differently whether xp boots virt or natural (i was hoping it would eventually come to recognize 2 sets of hardware, with drivers for both installed), it chokes when a partition that was a singular device suddenly has a context of other partitions around it.

so it remains to be seen whether even simulating the natural partition layout in the virt instance would let the same xp instance boot both virt and natural. (i suspect it would present conflicts when filesystems are mounted directly and simultaneously in multiple guest os', but then i might be too tired to fully theorize this matter; alas, i moved on..)

my particular arrangement presents additional factors which contributed to the fast-track elimination of possibilities; i have a fairly recent shuttle pc, it currently has an ide dvd buner, which due to the compact design and omission of any cable slack, can only be the first ide device on the chain. i think this was a problem in some circumstance or part of the xp install, since xp must write nt loader files to a partition on the first ide device. i've circumvented this in the past thru some combination of disconnecting cables while installing, but didn't apparently take much notes so i'm struggling to recall the details. on top of this first-ide issue, all my boot partitions were meant to be on a specific 10,000rpm sata hd, which is faster than the average 7200rpm ide hd, and partitions in an order that matched my exacting specifications, and xp really really did not like being relegated to an extended (5th) partition on technicaly the 3rd ide device.

for the current inventory of environmental resources, i think i gave it a sporting chance, and u gotta believe i'm going to revisit all this with a vengeance when i can drop a few more drives in there and start soloing partitions, and simplifying thru isolation.

as it stands on my desktop i have fc8 x86_64 as my default boot; i conceded the notion of xp virt in linux actually on my desktop when i remembered i already have that running on my htpc, whose nature is much more idle and serving so it lends itself perfectly to hosting a guest os such as xp, for light photoshop, and everything else win32 i ever had going. getting back to what made this arrangement so great to begin with, is that it's (allways) running on a server, and accessible simultaneously on my tv, and on my desktop.

when last i left it i was stuck trying to get xp as a dual-boot on the 5th partition of the 3rd ide device. it's not an impossible hurdle, just one which getting the floppy windows going in fc8 x86_64 took precedence over, which u hafta believe has a much more massive payoff at the end of an all-nighter.

at (or near) the end of it all, fedora 8 has been fantastic. fc7 on my htpc hasn't yet lost it's factory fresh smell, and i'm already outlining the transition to fc8, having been swooned by its breeze of use and lack of relative complications.

of particular note was the order of operations when getting fc8 x86_64 kde live dvd off the ground. i spent one all-nighter exploring the linux and xp dual virt action, and another starting fresh trying to recreate the 'magic' that occurred on the first all-nighter. the problems arose when after a fresh live dvd "copy to disk", u can't first then go and remove all the packages u don't want. removing this dearth of packages lead to an unbootable fedora; something about unexpected disk inconsistencies, check forced, and i chose to start fresh when my allready fresh install was offering to start salvaging files for me.

live dvd install, install updates, remove unwanted, install additional. kinda makes sense when u think about it, but i initially preferred to remove unwanted first, so with regards to file fragmentation, the updates would live early on the disk in the space left behind the unwanteds; suck it up kiddo, u'll just hafta get over that one..

and lastly also of note was the beryl-style compiz-fusion setup; it was the reason for a significant portion of the 2nd all-nighter. having figured it all out, it can be done with the breeziest of ease, but i sure had to try every non-functional option before getting it right.. there's a load of outdated information out there, which i guess lets u follow the matter in a historical sense, but it's time to update what's out there, and that's what's next; installing compiz-fusion (vs. beryl) in fc8. i've pretty much mastered compiz-fusion, and while i applaud it's progress, and want to document my setup procedure, i'm going back to beryl.