Documentation "containers"

I told you why I think Linux is a better choice of a host OS for virtualisation than Windows is - because I think virtualisation could be a good way to deal with some of the testing issues you seem to be having. If you don't want to use Linux, or don't want to use virtualisation, that's okay by me. But you don't have to waste everyone's time - and your own time more than anyone else's - by going through endless lists of "toys" that you believe are not supported by Linux.

I have measured speeds, and seen that in some situations the virtualised machine /can/ be faster. For cpu or memory speeds, it is unlikely, but since there are things that one OS will do faster than other OS's, you can easily have a virtualised machine with a different OS running tasks faster than the host machine.

A few years ago, I used to run WinMe on a Win4Lin virtual machine hosted on Linux, and it was _way_ faster than running WinMe directly on the same hardware.

Apparently, the Win4Lin Windows device drivers for X11 and the Linux network, and disk/filesystem APIs ran rings around the "native" WinMe drivers for my hardware. It was also far more stable on the virtual machine than it was on real hardware. I think that's mainly an indication of how stunningly bad WinMe was.

The times I've run Win2K and WinXP on various virtual machines (mostly Qemu and VirtualBox) they don't seem to benefit from any speedups.

--
Grant Edwards               grant.b.edwards        Yow! Will it improve my
                                  at               CASH FLOW?
                              gmail.com

--------------------------^^^^

I was trying to address the range of "toys" that clients drop on my lap and expect me to either use or evaluate. And, by extension, how much that "mucks up" a running (Windows) system.

Using virtualization to let me do *some* things -- and then

*still* needing "real hardware" to do *other* things that the virtualization was unable to address -- means I have to have that hardware *and* your virtualization as well. How does that make my life any easier?

"Gee, it appears (after *trying*) that this won't work under a VM without mucking with my host OS -- hopefully, it hasn't done anything that I can't *un*do. So, now I guess I'll have to take out one of those machines that I've set aside for this sort of thing..."

vs.

"I'll take out one of those machines I've set aside for this sort of thing and wipe it clean, afterwards..."

As I said, after I image those boxes, I'll install VB as a "guest application" and *see* what it does and doesn't do for me; see what sorts of performance hits it incurs; where it's behavior differs from "native hardware".

Then, restore the original image and repeat the exercise with VMware. So I have real facts instead of "try it and see..."

Terribly sorry to have wasted your time with these details. I'll spare you the trouble of reading my summary results (since they wouldn't apply to *your* "toys", hosting iron, etc.)

80% of the population don't know how to use a hammer properly.

In the female population, that rises to 90% ;-)

--
"For a successful technology, reality must take precedence 
over public relations, for nature cannot be fooled."
                                       (Richard Feynman)

True.

100% of females over the age of 4 know how to use tools properly ... they get a male to do it for them.

George

Then you only know conniving women.

--
You can't have a sense of humor, if you have no sense.

I know a hell of a lot more women who know how to control a man than a hammer (and will argue that there isn't much difference ;-).

be a

only

speed,

faster

I know that there are various (popular[?]) free tests, none of which = trust much. But i not interested enough to pay much for test software. Nor is CPU intensive the only type of test i am interested in.

I get the point. It would not serve me all that well in general. VM snapshots work pretty well for me though.

?-)

Benchmarks are only good for folks writing articles in magazines. I want to know how it will perform on the types of software that

*I* need to run. I.e., how big a hit I take on physical memory, I/O devices, etc.

I figure CPU intensive give it the *best* chance of performing well. No need to work its way down through abstraction layers to deal with

*real* hardware (i.e., "I/O").

Of course! You use what's right for *you*. If I was just running code that used a display/keyboard/mouse/disk I would have a different opinion. It's precisely the hardware dependencies that I (know?) will bite me. In which case, if it doesn't solve *all* those needs, then why add one more thing to the "support"/dependency list? :<

That depends on the comparitive quality of the driver frameworks and I/O subsystems of the two OSes, and how the virtualization works. If the client is running a crappy OS (e.g. Windows), and the client is using network/disk/whatever drivers that are virtualization-aware, then it's quite possible that I/O intensive apps will experience noticable accelleration compared to running directly on the hardware.

The best you can hope for in the case of CPU intensive tasks is to operate at the same speed as they would directly on the hardware.

--
Grant

It also depends on the virtualization software. Obviously mileage may vary, but I have found VMware to be the most stable, most versatile (in terms of systems it will run) and best performing on both Windows and Linux hosts.

VirtualBox runs very well on Linux but on Windows I have found the I/O to be slow, and I've had occasional unexplained hangups trying to run Windows clients.

If you are virtualizing Windows on Windows, VirtualPC works very well ... but I've had trouble trying to run other clients.

I'm always on the lookout for something better, but so far for me VMware has proven to be the best solution.

Non-privileged code should run at 95+% of the raw CPU speed. You do take a slight hit with thread scheduling in the client OS because the context switch involves some privileged operations that have to be emulated.

George

Those types of drivers are only likely to be found in network, storage and display devices -- places where there is lots of data and a reasonably "generic" use of it. Chances are, the "toys" I enumerated are unlikely to be able to benefit from any such "efficiency hacks".

Generic storage is easy to exercise with pseudo-random (not sequential which could easily be fooled by caching) reads and writes to very large files (or, perhaps the raw storage device itself).

As for the display, running an X server *in* the guest OS -- or, to be brutal, perhaps a first-person shooter! :>

(On the SunPCi2, the latter runs at full speed -- since the card has its own video hardware, etc. When running an X server *through* the Solaris video device, things get noticeably slower -- especially when viewed over a *remote* X connection :-/ )

Assuming constraints on the VM don't make this *worse*. I.e., the VM will always have less physical memory available to it than the host OS -- my "reimage the disk" approach lets the OS have whatever memory is present (since there is no host OS to share it with).

I suspect I will find that most of these hardware devices "just don't work" (without tainting the host environment).