Lone Coder: VirtualBox on Vista with a Gentoo Guest

[Jamon Camisso]

CLIFFORD ILKAY wrote:
> Jamon Camisso wrote:
>> Ken Burtch wrote:
>>> Based on experience, the cost of installing Gentoo on VirtualBox was 
>>> signficantly higher that installing Fedora, especially when Fedora 
>>> supports VirtualBox right "out of the box" and Gentoo does not.
>>
>> If speaking about costs, as you've discovered there can be time costs 
>> up front. But now you know how the system works, don't have to do it 
>> again, and have an article to show for it. Not bad in my estimation.
> 
> You don't ever have to reinstall Gentoo... until you do. Gentoo is a 
> useful learning tool but I don't have much use for it beyond that. 
> Granted, you don't have glibc changes that require *everything*, 
> including the build toolchain, be rebuilt all over again all the time 
> but when it happens, the results are non-deterministic, or at least they 
> were up to two or three years ago. It didn't take me long to find tales 
> of woe on the Gentoo forums about how many passes people had to make 
> rebuilding things (and one more for good measure!) to (maybe) get 
> everything rebuilt and working. No thanks. I'll pass. Gentoo is nice if 
> you want to create a custom distro that only you can (maybe) maintain.

Yep, it can be a headache to maintain more than one or two, especially 
if they weren't your boxes in the first place. But I expect someone on 
the list will chime in with the age of their oldest up to date gentoo 
box that has only had one install in the last X years. Anyone?

>> Now that you've seen there are different ways to get Gentoo setup, try 
>> debootstrap and build a Debian system that way. My guess is that you 
>> won't be so put off by Gentoo's method :) That said, I pretty much 
>> only use debootstrap for new installs since it is so easy once you get 
>> the hang of it. The best part is that Fedora, Gentoo and others all 
>> include it so I can Debianize practically any system. Sweet!
> 
> Debootstrap in a virtual machine is an excellent way of deploying Debian 
> or its derivatives. That how we deploy both in Xen and OpenVZ virtual 
> machines in our hosting environment.

I typically build as small an image as I can e.g. working ssh with a key 
for login and that's it. Small means easily copied and deployed as a new 
domU for my purposes.

> Gentoo and Debian fans criticize Red Hat and derivatives because it 
> (supposedly) can't be upgraded in situ as Gentoo and Debian (supposedly) 
> can be. I've upgraded Fedora servers but I prefer to "nuke 'n pave", 
> especially since it's so trivially easy to do with Cobbler 
> <https://fedorahosted.org/cobbler/>. I've upgraded Debian and Ubuntu 
> servers where I typically don't install X and a desktop manager or such 
> and it worked as advertised. Desktop machines are a different story, no 
> matter what the distro. With the big changes in KDE, for example, 
> upgrading really doesn't get you much since there is no way to migrate 
> some (many?) of the config files anyway.

Not sure, I remember being presented with a migration tool when kde4 
first came into Squeeze, all my stuff still seems to work as I 
expect/remember. But in my narrowminded Debian world, I have no idea how 
well it would work in Fedora for example.

> Let me just expand on Cobbler. Last week, I was at a client where I 
> demonstrated a hands-off, bare metal installation of CentOS 5.3, over 
> PXE. From selecting the PXE menu option to having a machine that was 
> ready for use, it was about 20 minutes, and that included creating 
> filesystems on a 1TB disk presented by hardware RAID. (The RAID set had 
> been created prior to the installation. It was left running over the 
> weekend building the array.)

LOM+PXE boot is awesome. I've recently started using it with ipmi on 
host servers for clustering filesystems too (gfs2 as it turns out, ocfs2 
noes seemed prone to dropping out of the cluster). Really fun stuff.

Also r.e. PXE boot, the linuxcaffe was making extensive use of it for a 
while and it seemed to work really well. XDMCP is being used now I think 
since it isn't as hardware dependent. I haven't tried it, but 
http://boot.kernel.org looks neat (as long as you trust it, which I 
don't particularly).

> Once we had the working CentOS machine, to create another CentOS 
> installation in a Xen virtual machine was a matter of running "koan" and 
> pulling a kickstart installation from the Cobbler server. That took 
> another 10 minutes. By contrast, the first Xen installation I did back 
> in 2005, took me a *week*.

There is a pretty steep Xen learning curve, and building newer dom0 
pv_ops enabled kernels is a black art to me still. Can't wait until the 
code goes into mainline kernel.org sources, see 
http://wiki.xensource.com/xenwiki/XenParavirtOps for more on that.

> I believe the Cobbler approach, particularly if it's used in conjunction 
> with a configuration management system like bcfg2, cfengine, puppet, 
> chef, etc., is a far better solution to systems management than doing in 
> situ upgrades and ad hoc systems administration that often accompanies 
> that practice. If the cost of recreating the environment is so high that 
> you value in situ major upgrades over bare metal installations, you have 
> a problem. You most likely have an environment that can't be replicated 
> in a reasonable amount of time, if it can be replicated at all, which 
> does not bode well for disaster recovery.

Cobbler does look useful for installs, better than virt-manager I 
suppose? Will have to look into it some more. I'm not sure I agree with 
you about upgrades though. For systems I'm working on in an academic 
research setting, where developers are used to playing with shiny new 
code for their research, domU is unique enough that it usually requires 
some hands on work to maintain. Especially since there isn't just one 
distribution in use. I'm not sure how cfengine could help automate 
upgrades in this particular (albeit somewhat unique?) setting.

For us, rsnapshots really help with replicating an install to a given 
point in time. I haven't used anaconda and kickstart so I don't know how 
it handles config files, but rsnapshot for pitr on fibre channel disks 
seems fast enough that there isn't much cost timewise if something goes 
terribly wrong. But then having root on a domU (and having a non-uniform 
target for images) isn't a given so I can see your point.

In the end I guess it is a matter of different user bases and 
requirements. In environments like these there is no one size fits all 
solution, so knowing Cobbler is out there will be a handy thing indeed, 
thanks for the explanation.

Jamon
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists