[THIN] Re: VMWare ESX Server
- From: Angus Macdonald <Angus.Macdonald@xxxxxxxxxxxxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Thu, 9 Dec 2004 13:16:23 -0000
The clincher for me is the fact that we have lots of unique servers with a
huge array of different hardware configurations. If one goes down it's not a
simple task to restore from backup because the hardware on the replacement
server is invariably different, neccessitating a complete OS rebuild as a
starting point. With VMWare, I can move a server image to another VMWare box
and know it'll come up straight away, regardless of the hosting hardware.
Also, I can consolidate over 30 legacy servers into 6U (so far ).
-----Original Message-----
From: Joe Shonk [mailto:joe@xxxxxxxxxxxxxxxxxxx]
Sent: 09 December 2004 13:00
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: VMWare ESX Server
I call it the "common sense" methodology. Use it when it makes sense.
Every environment and every situation is different. Each client has a
different objective and goal when it comes to technology (and of course that
changes over time too!). If the technology makes sense, use it. If not,
then move on.
It's just like Metaframe. It's a great product, but it's not a cure all.
There are some situations where it not a suitable choice and another
solutions needs be devised.
Joe
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Ron Oglesby
Sent: Wednesday, December 08, 2004 8:44 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: VMWare ESX Server
I would totally agree. Obviously there are tons of servers/apps that are
"not a perfect fit". But on the consolidation side, servers that are really
under utilized (<30% on any of the core four resources) it's a no brainer.
Now if you have servers that DON'T perform as well in the VMworld given the
same amount of memory and other resources, then you have to make the
business decision if the benfits of a VM are wroth the cost of making TWO or
more VMs to split the load.
On a consolidation front two studies I have done for clients put the VM to
Phys machine (when looking at consolidation) at about a 1:3 cost ratio. On
the non consolidation front, those non0strike zone servers takes that up to
a 1:1 or 1:1.25. Now if it's a mixed environment of strike zone and
non-strike zone consolidation servers then we are somewhere in between.
Anyway if you are going to POUND a server then maybe physical is better
unless you need one of the other features, like near instant recovery. Then
the additional cost becomes part of your DR scheme and not really
provisioning itself.
Ron Oglesby
Director of Technical Architecture
RapidApp, Chicago
Office: 312 372 7188
Mobile: 815 325 7618
email: roglesby@xxxxxxxxxxxx
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Chris Fraser
Sent: Wednesday, December 08, 2004 12:47 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: VMWare ESX Server
Hi there Brian
I would disagree that virtual anything can never be as good as the real
thing. In fact I think VMware ESX-based anything can be quite a bit better
than the real thing _BUT_ you need to have a good understanding of your
workload and usage patterns (sound familiar anyone?).
Hardware-cost and form-factor are trivial expenses compared to the overall
TCO or $$$ impact of downtime.
I've seen scenarios where the vendor, with a minimum of troubleshooting or
problem isolation, pointed the finger at VMware. After further investigation
we were able to determine that the issue was actually the application or the
OS and it was only exposed or magnified by running on VMware.
VMware will not give you something for nothing. It is absolutely key that
you understand what you have and where you need to get to and then plan and
build it accordingly.
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of RMC - Brian Hill
Sent: Wednesday, December 08, 2004 10:24 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: VMWare ESX Server
I've never been a fan of VMs in the production environment. I have used
them for development a few times, but even then, I prefer a "real world"
scenario for development as well. I've had DC's that were flaky, with the
only variable being VMWare. Dunno, maybe it's just me. Hardware cost are
relatively cheap these days, the form-factor is small, so I don't think VMs
buy you a whole lot. They have their place I suppose, but they are not
something I pursue. Virtual "anything" can never be as good as the real
thing IMO.
Brian
-----Original Message-----
From: Jennifer Hooper [mailto:jennifer.hooper@xxxxxxxxxxxxx]
Sent: Wednesday, December 08, 2004 12:23 PM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] VMWare ESX Server
Hi Guys -
Here's the situation. We are about 1/4th of the way through converting
our production data center (full of old, out of warranty Compaq servers) to
IBM BladeCenters running VMWare ESX Server 2.0 (I think... whatever the
latest version is). We use Platespin to convert the physical server to the
VMWare image and move it over to the Blade it's going to live on. Right
now, we have an average 5 servers per blade planned, and several have
already moved over, because the hardware failed that they were on. However,
some of the application folks are uncomfortable with this solution, not so
much the Blade technology, as the VM technology. Needless to say, we're
already experiencing failures, and stuff not running right - performance
issues, network issues, etc. (Can you believe that they are going to run
our Root Domain Controllers on this?) I have already experienced a drag on
one of my Citrix servers that moved to virtual space, and can't fix it up.
So what I would like to do before things get too much more hairy, is to
try to find out what the success rate of running something like this in
production, and if there are a lot of people out there doing this. Feel
free to share with me any nightmare stories too! :)
Thanks much!
Jen
Jennifer Hooper
Peregrine Systems, Inc.
Sr. Network Engineer
mailto:jennifer.hooper@xxxxxxxxxxxxx <mailto:jennifer.hooper@xxxxxxxxxxxxx>
Gallai'r e-bost yma gynnwys gwybodaeth gyfrinachol a/neu ddeunydd hawlfraint.
Os ydych chi'n meddwl eich bod wedi derbyn yr e-bost yma drwy gamgymeriad rydym
yn ymddiheuro am hyn; peidiwch os gwelwch yn dda â datgelu, anfon ymlaen,
printio, copïo na dosbarthu gwybodaeth yn yr e-bost yma na gweithredu mewn
unrhyw fodd drwy ddibynnu ar ei gynnwys: gwaherddir gwneud hynny'n gyfan gwbl a
gallai fod yn anghyfreithlon. Rhowch wybod i'r anfonwr fod y neges yma wedi
mynd ar goll cyn ei dileu.
Mae unrhyw safbwynt neu farn a gyflwynir yn eiddo i'r awdur ac nid ydynt o
anghenraid yn cynrychioli safbwynt neu farn Ymddiriedolaeth GIG Gogledd
Orllewin Cymru.
Gallai cynnwys yr e-bost yma gael ei ddatgelu i'r cyhoedd o dan Gôd Bod yn
Agored y GIG neu Ddeddf Rhyddid Gwybodaeth 2000. Nid oes modd gwarantu
cyfrinachedd y neges ac unrhyw ateb.
Bydd y neges yma ac unrhyw ffeiliau cysylltiedig wedi cael eu gwirio gan
feddalwedd canfod firws cyn eu trosglwyddo. Ond rhaid i'r sawl sy'n derbyn
wirio rhag firws ei hun cyn agor unrhyw ymgysylltiad. Nid yw'r Ymddiriedolaeth
yn derbyn unrhyw gyfrifoldeb am unrhyw golled neu niwed a allai gael ei achosi
gan firws meddalwedd.
This e-mail may contain confidential information and/or copyright material. If
you believe that you have received this e-mail in error please accept our
apologies; please do not disclose, forward, print, copy or distribute
information in this e-mail or take any action in reliance on its contents: to
do so is strictly prohibited and may be unlawful. Please inform the sender
that this message has gone astray before deleting it.
Any views or opinions presented are to be understood as those of the author and
do not necessarily represent those of the North West Wales NHS Trust.
The contents of this e-mail may be subject to public disclosure under the NHS
Code of Openness or the Freedom of Information Act 2000. The confidentiality
of the message and any reply cannot be guaranteed.
This message and any attached files will have been checked with virus detection
software before transmission. However, recipients must carry out their own
virus checks before opening any attachment. The Trust accepts no liability for
any loss or damage, which may be caused by software viruses.
Other related posts:
