Hi Christian
You only pay for the PHYSICAL cpu:s in the machine(the processors
installed physically in the machine).
For example, we've got a customer running two Unisys servers, each
equipped with 24 cpus:s. On theese Unisys machines, he's got multiple
VMWare instances running. The customer only needs("only") to pay for 2 *
24 cpu:s, independent of how many VMWare instances hes running.
This is good if you're only running fileservers(Backup/Archive clients).
However, one day, the customer decided to install a SQL cluster in on of
the VMWare instances(clustered between the two Unisys machines). Here's
the catch: the SQL server only consumes about 2-3 processors. However, the
customer still needs to buy 2 * 24 TDP for SQL cpu licenses. This means,
running an SQL within an VMWare instance, means the customer has to buy 48
TDP for SQL licences(which are not cheap).
The customers nightmare will be one day when he decides to install an
Oracle cluster on the Unisys machines. That will mean he'll need to buy 48
TDP for SQL cpu licenses. In the longterm, this means that the customer
has bought 48 B/A client licenses, 48 TDP for SQL client licenses and 48
TDP for Oracle licenses. Thats cheap....
Sometimes it's good to consolidate, sometimes it isnt...
And I'd like to see the machine running 500 VMWare instances.... Despite
the fact that theese large machines can run a high load, it doesnt mean
you can consolidate all your servers onto one machine...
Best Regards
Daniel Sparrman
-----------------------------------
Daniel Sparrman
Exist i Stockholm AB
Propellervägen 6B
183 62 TÄBY
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51
Christian Svensson <christian.svensson AT CRISTIE DOT SE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2003-12-03 17:25
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: SV: TSM and VMWARE
Hi!
But I think in VMWare can you dedicate CPUs how many CPUs to each virtuel
machine.
So in that case. How do you count the CPUs then? By each virtuel CPU or
buy physical CPU * each virtuel machine?
Hmmm..
A co-worker to me told me that he have read somewhere that you only pay
for the physical CPU. And does´nt matter how many Virtuel Machines you
have. So if you got 10 CPU and 500 Virtuels Machines. You only pay for 10
CPUs and no more.
I don´t know if this is correct. But can someone comfirm that?
But about to use VMWare and together with TSM.
Many of all our customers here in Sweden runs VMWare in one or another
way.
And everyone is happy about it. And it´s help them in many ways. And
specialy in disaster recovery situations where a imported server have
crached and together with CBMR/TSM has they restore that server to a
VMWare virtual machine. And then can the customer easy rebuild his machine
from scratch without any time limit.
And we have also see that. Windows is runing much better on a VMWare
server then a normal hardware.
Good luck guys
Christian Svensson
-----Ursprungligt meddelande-----
Från: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]För Coolen,
IG (Ilja)
Skickat: den 3 december 2003 08:59
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: Re: TSM and VMWARE
Rod,
We are currently in the same process of trying to consolidate on VMWare.
We have a TSM client running succesfully on the Linux-Base of the Vmware
box, giving us a chance to backup complete Wintel guest operating systems
as
single files, having the guest OS's suspended of course. This creates the
best DR possibilities.
We are in the process of using ESS/FlashCopy to do an instant backup of
the
complete Vmware box, and offload those copies to TSM. Which reduces the
suspend time.
When doing TSM backups on the Wintel guest operating systems on the
VMware,
you should treat the windows OS as if it were a stand-alone Intel box
running windows, so the TSM support should not be different. But that's my
theory.
As for license issues; TSM is licensed against the number of CPU's in the
physical machine. Now lets run 20 guest OS's on a single 4way Vmware
machine.
This was confirmed by our local Tivoli rep., but I still have my doubts.
Nice theory though.
All this is very nice, but we don't have a Tivoli support confirmation
yet,
so we have no production environments running like this at the time.
Greets, Ilja
-----Oorspronkelijk bericht-----
Van: rh [mailto:rh_info_store AT YAHOO DOT COM]
Verzonden: dinsdag 2 december 2003 16:53
Aan: ADSM-L AT VM.MARIST DOT EDU
Onderwerp: TSM and VMWARE
Like many companies, we are attempting to consolidate
multiple Wintel servers into VM's using VMware. Does
anyone know if IBM supports TSM 5.2 servers and
clients running under VMware? I see on VMware's web
site that IBM is a "software alliance partner" and TSM
is listed as supported. I can't find any IBM site that
states this as being true, or the VMware/TSM
combinations that are supported or tested. I don't
want to get into a situation were I will have to
recreate a TSM problem in a standalone environment in
order to get support. Is anybody running this
combination and received support from TSM?
Many thanks,
Rod Hroblak
ADP
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
=====DISCLAIMER=================================================================
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd
voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken
wij u contact op te nemen met de afzender per kerende e-mail. Verder
verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud
ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid
voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud
van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.
The information contained in this e-mail is confidential and may be
privileged. It may be read, copied and used only by the intended
recipient. If you have received it in error, please contact the sender
immediately by return e-mail; please delete in this case the e-mail and do
not disclose its contents to any person. We don't accept liability for any
errors, omissions, delays of receipt or viruses in the contents of this
message which arise as a result of e-mail transmission.
|
