> Because the hardware features to permit efficient virtualization weren't > available on i386-only CPUs. (And there's really no good reason to run a VM > host [vs guest] in i386 mode if it can run in amd64 mode.)
By "there's really no good ..." I think you mean "I can't think of any good ...". For reference, here's the reason why I did it last time: I needed to update the small Debian install I have on my USB rescue key. I had a few choices: - boot inside a qemu on my 32bit Debian system. - reboot my system into the rescue key (hence losing the current state of my session and all that stuff and being unable to use my machine for anything else while that rescue system was updating itself). - do the same but hoping that hibernate+resume will work, so while I still can't use the machine during the upgrade, at least maybe I didn't lose all my session's state (tho resume often fails, in my experience). - start by reinstall Debian using a 64bit system this time, just on the hunch that maybe it'll be marginally faster at running the upgrade within the VM (tho this is normally limited mostly by the USB key write speed). Now, which of those choices sounds more silly to you? In my experience VMs running in a 32bit Debian system on a Core 2 processor (i.e. one of the first amd64-compatible CPU from Intel) offer adequate performance. I probably wouldn't use that for a server under any real load, but VMs can be useful in all kinds of situations. > It's certainly possible to run software-only virtualization on an > ancient CPU, but at that point (since it would clearly just be to > scratch an itch, not for any practical reason) why ask for opinions > instead of just playing around if playing around is the only goal? I get the impression that by "if playing around is the only goal" you mean something like "if it's not within the context of a commercial deployment". Sometimes the need is very real (not just for playing around) but doesn't have anything to do with maximizing hardware utilization in a datacenter. Stefan