Re: HVM Guests (was Re: [Xen-users] Warning regarding AMD Athalon 64 4200+(HVM/AMD-V))

[Tim Post <tim.post@xxxxxxxxxxxxxxx>]

On Thu, 2006-11-02 at 07:50 +1300, Julian Davison wrote:
> > For those evaluating the AMD X2 4200+ series for the purposes of running
> > HVM guests, take a note below before purchasing if the server you are
> > purchasing happens to be made by HP.
> 
> Buy an IBM x3650 ;)

I'm too much of a bargain hunter for "lab" servers. I'm more likely to
take supermicro specials or whatever is on sale at newegg that roughly
matches what I need. Plus I have fun assembling and building my own. Our
configurations are rather unique, buying proprietary brands gives us a
bunch of junk we don't really need.. and we don't do enough volume to
warrant companies like IBM taking custom requests from us at pricing
that remains below budget.

> While I'm only really looking at HVM as a interesting
> experiment, I'd like to hear what other people are doing
> with it...

My primary business is HA/HPC clusters (building of them), specifically
to try several solutions to make a firm recommendation to a client so
they know which works best and hand the kernels / images off to their in
house guys to erect and play with.

Un modified guests lets me run several independent clusters with
unmodified kernels (such as OpenSSI) on the same physical servers,
allowing us to test several kinds of applications on said cluster type
at once.

Maximizes lab use and in some cases is even suited for production. Also
lets us hang a Windows box on the network to test & develop
administrative GUI's to control said Linux based clusters, no more need
for a bunch of switches to simulate a few independent networks, etc. 

In essence, where once we needed a dozen test boxes , we can now get
away with 3 or 4.

HVM support keeps you from "marrying" your framework to a particular Xen
build .. since no modification of the guest kernel is needed. We found
that we spend less time and money navigating the nuances of the hvm
loader than we would re-patching kernels (like OpenSSI) from 2.0.7 over
to 3.0.3.

When you use DC management suites like openqrm to facilitate a single
Xen image and pxe boot your nodes, its cruicial to *not* be married to a
certain version facilitating oddball para virtualized guests.

To upgrade, I simply have to place the new kernels in the pxe config and
update only 1 root image. The leap from 2.0.7 to 3.0.3 was the only
(serious) one we had to make.. the rest should be pretty easy because
the "special" guests largely remain unmodified. 

I think we squeeze a little more out of Xen than the average user,
however. The above took us well over a year to get working in such a way
that its easily re-deploy-able, and I still have a laundry list of bugs
to get out of it.

Best,
-Tim


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users