[Beowulf] Repenting for sins against Dell (on good Friday, no less)

[Robert G. Brown]

On Sat, 18 Apr 2009, Andrew M.A. Cater wrote:

> KVM would appear to eat VMWare's lunch when properly implemented. Across
> 500 machines, VMWare becomes prohibitively expensive in terms of
> enterprise licence fees and overall administration - and I also have
> a private "thing" against proprietary kernel modules that have to be
> changed with every upgrade.

Duke manages it somehow -- they just got a site license, unlimited.

Aside from the usual open source preferences, etc.  Sure, I'd rather use
something free and functional, but I am not averse to buying software.
I just have my own ideas of what kind of value has to be added to make
it worthwhile to buy software.

So far, vmware adds a lot of value.  On my very next system, I may give
KVM a try (again) but the last time I tried it and Xen, they didn't hold
a candle to vmware and vmware has significantly improved since then.
The vmware workstation console (for example) is pretty amazingly
functional, and the server console and products make quite a few
essential aspects of maintaining a server farm with redundant VMs very
straightforward.

I do think vmware's server products are absurdly overpriced -- they make
the same mistake RH does and create SUCH an enormous price differential
between their enterprise server product and Centos that even people
(like myself) that would be happy enough paying them some money balk.
The same is true for vmware's free vs nonfree servers -- you have to
really want the enterprise level added value stuff in the nonfree stuff.
Nobody seems to want to shoot for low cost high volume to make their
money, which is pretty absurd given free alternatives.

As far as the kernel module thing is concerned -- that is really no
longer an issue in the GUI workstation versions.  Post a kernel upgrade,
when you start vmware the first time it pops up a window and says oops,
you need to rebuild your kernel modules, ok?  You click yes.  45 seconds
later it finishes and starts up.  45 seconds every six to twelve weeks,
transparent, is really not an issue.

Server side it is probably MORE of an issue -- I don't know how this
scales or what they do in the case of larger installations.  It is also
still far from what they COULD do if they, too (like Dell) implemented a
proper RPM repository.  Since they use per-host installations of license
keys (instead of a networked local server) they don't even need to
authenticate the yum repo -- all they'd need to do is ensure that their
product is rebuilt in phase with the kernel.  That MIGHT be a problem
for them, I don't know.  The way they do it now at least ensures that
there is no real delay between updating a kernel and rebooting and
having valid local modules.

I have heard that KVM is improving rapidly, though; maybe it does, by
now, "eat vmware's lunch".  When I pop to Fedora 11 or 12 (or bring
another system up to 10 -- hmmm, I do have a box or two that need this
done) I'll compare and contrast and if there is any interest, I'll even
report back here.  Since they'll both be free TO ME and since I have
clients that are currently using vmware at the enterprise level that
would be perfectly happy to move to all-free Centos+KVM, it will be a
very fair comparison.

In particular I'll be looking at how easy it is to crank up the VM
interface, (re)configure the VM, install the guest, move data and mouse
and objects between vms, run guest vm applications on the native host
"transparently", permit configuration of e.g. shared disk and the
NAT/bridged network(s), back up the VMs (via scriptage in the case of
server images, and manage a collection of VMs per host and hosts per VM
interface.  These are all things that vmware does very, very well.
Quite seriously, I'm rather addicted to the vmware workstation interface
because it makes it so damn EASY to boot, stop, snapshot, reconfigure,
install, or otherwise screw around with a vm guest.  Click.  Click.
Click.  One doesn't have to know diddly about command lines and kernel
parameters and networking to get a functional VM installed -- one just
needs base media (CD, DVD) or the base iso -- something to boot.

It is EASIER to install an operating system under vmware than it is to
install it native, because you do it under an already functioning system
and can grab the install iso's, hotwire them as boot images with a click
or two, and boot.  You can even do work back in the host OS while
waiting for the install to finish, and Windows boots and shuts down
faster as a vmware guest than it does native.

vmware is not perfect.  It does cost money to get anything but the
vmware player or free server product (which actually has an interface
very similar to that of the workstation product).  It has DRM (although
far from the worst DRM that I've seen -- it is relatively translucent,
if not transparent).  But I've paid money out of my own pocket for it in
the past because it is (or was) worth it, compared to what I could get
otherwise.

>> I'm not so sure about that - why would VMed windows be more secure?
>> my understanding is that the thing that makes windows vulnerable is the
>> hooks that make windows integration work.  and it's the integration
>> that people expect, no?
>
> VM'ed Windows: you can reduce your Windows to a minimal footprint,
> firewall the VMs, use SE Linux and do everything else to produce a
> maximally secure VM infrastructure. When it fails, just get the clean
> instance of the VM again. If you deny Windows access to a network, email and
> the Web unless severely filtered and ensure that the VM can be
> replaced/regenerated in an instant then you're starting to produce something
> workable. [A silk effect sow's ear purse if seen subject to the right
> lighting constraints ... ]

Exactly.  There are two ways to run Windows securely.  One is to get
yourself or hire an above average MCSE (one who really is competent) and
set up a fascist locked down network off of a Windows server, one where
users cannot do anything to their individual systems and where
everything is severely firewalled.  Using XP Pro, of course.  The other
is to run Windows as a client only in a VM, which is more or less
equivalent to running it inside a private per-system firewall, locked
down NOT by an MCSE but just by taking a vm snapshot and freezing it
post installation, and updating that snap quite deliberately only when
necessary.  You do still need enough expertise to be able to provide it
with writeable user space outside of the frozen install, but one can
usually manage this with less than MCSE level skills.  Or just let the
primary image be writeable and update, but maintain the post-install
snap in epochs, safe to safe.

     rgb

>
> AndyC
>
>> _______________________________________________
>> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
>> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977