I don't buy the argument that the winning case is packaging up a VM with
all your software. If you really are unable to build the required
software stack for a given cluster and its OS, I think using something
you're right, but only for narrow-function clusters. suppose you have
a cluster used by 2k users across a handful of different universities
and 100 departments. and have, let's say, 2 staff. it's conceivable
that using VMs would permit a higher level of service by putting more
configuration flexibility into the hands of the users. yes, most would
use a standard image (which might be the bare-metal one, actually),
but making it easier to accommodate variance is valuable.
it even offers the ability to shift the model - instead of actually
booting VMs on nodes for a job, how about just resurrecting a number
of VM instances (freeze-dried in already-booted state)? that makes
the setup latency potentially much lower. (pages from a VM image can
be fetched lazily afaik, and presumably also COW.)
for the few HPC-oriented performance studies of VMs I've seen,
the only slowdowns were for OS activity (IO, page allocation, etc).
an ideally-behaved HPC app minimizes those already, so...
_______________________________________________
Beowulf mailing list, [email protected] sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
