Maker Pro
Maker Pro

Documentation "containers"

G

George Neuner

Jan 1, 1970
0
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.

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.

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.

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
 
D

Don Y

Jan 1, 1970
0
Hi Grant,

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.

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 :-/ )
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.

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).
<shrug>
 
Top