What are the practical (or real) advantages of Intel VT and TxT technology (Q8200 vs Q9300) ?
Intel Guy
The 8200 is listed as not having Intel "virtualization technology" nor
Intel "Trusted execution technology".
What are the implications of not having those two technologies for a
desktop developer system running 64-bit XP-pro with 8gb ram?
What will I absolutely not be able to do with a Q8200 (and what will be
a major or minor pain, but still possible to do) compared with having
the Q9300?
DevilsPGD
claimed to have wrote:
If you're missing VT you'll never be able to run Hyper-V (which is
mainly a server technology anyway), and other virtualization software
will perform more slowly although for the moment everything else still
runs.
Yousuf Khan
> With regard to, say, the following 2 processors: Q8200 and Q9300
>
> The 8200 is listed as not having Intel "virtualization technology" nor
> Intel "Trusted execution technology".
You'll miss virtualization technology, but absolutely not miss trusted
execution technology. Virtualization will for example let you run Linux
under Windows, or vice-versa.
Trusted Execution is otherwise known as DRM. Not having it will make
your life much simpler.
Yousuf Khan
Intel Guy
> > The 8200 is listed as not having Intel "virtualization technology"
> > nor Intel "Trusted execution technology".
>
> Virtualization will for example let you run Linux under Windows, or
> vice-versa.
Is it an absolute given that I *won't* be able to run *any* sort of
virtualization if I don't have this VT?
If I have 64-bit XP installed on this machine, and I want to run a
virtual 32-bit XP session, or even a virtual win-98 session, I won't be
able?
Alphonse Q Muthafuyer
>Virtualization will for example let you run Linux
>under Windows, or vice-versa.
You might wanna review good descriptions of:
1.) Virtualization and VM's.
2.) Emulation.
AQ
"The monkey and the baboon was playing 7-up.
The monkey won the money but he scared to pick it up.
The monkey stumbled, mama.
The baboon fell.
The monkey grab the money and he run like hell!"
- from "Dirty Motherfuyer", Roosevelt Sykes, around 1935
Tom Lake
> virtualization if I don't have this VT?
No. VirtualBox uses hardware virtualization if you have VT on
but it will run fine (albeit slower) with software virtualization.
Tom Lake
YKhan
> Is it an absolute given that I *won't* be able to run *any* sort of
> virtualization if I don't have this VT?
>
> If I have 64-bit XP installed on this machine, and I want to run a
> virtual 32-bit XP session, or even a virtual win-98 session, I won't be
> able?
No, there were software-emulated virtualization software before which
could still do what you want. Those were mainly provided by Vmware
which had this market pretty much to itself in the past: it had the
most comprehensive and mature virtualization suite. The recent spate
of competition for Vmware has been mainly made possible by the
introduction of the hardware virtualization services. So many of the
latest virtualization software does depend on the hardware, since they
didn't develop the full software-emulation strategies that Vmware has
done over several years beforehand. So it's not clear if the newer
virtualizers are as good or even could work at all without the
hardware backbone behind them. It's also not clear how much longer
even Vmware will maintain its old software stack in the face of its
simpler hardware stack being available.
Yousuf Khan
DevilsPGD
Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>On Tue, 17 Mar 2009 18:25:26 -0400, Yousuf Khan <bbb...@yahoo.com> wrote:
>
>>Virtualization will for example let you run Linux
>>under Windows, or vice-versa.
>
>You might wanna review good descriptions of:
>
>1.) Virtualization and VM's.
>2.) Emulation.
The problem is that most modern virtual machine solutions are a mix of
virtualization and emulation, so the difference between the two concepts
is less well defined in practice.
andy
>Yousuf Khan wrote:
>
>> > The 8200 is listed as not having Intel "virtualization technology"
>> > nor Intel "Trusted execution technology".
>>
>> Virtualization will for example let you run Linux under Windows, or
>> vice-versa.
>
>Is it an absolute given that I *won't* be able to run *any* sort of
>virtualization if I don't have this VT?
No, it's not an absolute given.
>
>If I have 64-bit XP installed on this machine, and I want to run a
>virtual 32-bit XP session, or even a virtual win-98 session, I won't be
>able?
You will be able to.
Alphonse Q Muthafuyer
That's certainly news to me.
Can you substantiate?
Doesn't emulation still have a virtual pedigree from the American Kennel Club? :-)
DevilsPGD
Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>2771 2771 On Wed, 18 Mar 2009 13:39:35 -0700, DevilsPGD <Death...@crazyhat.net> wrote:
>
>>In message <9ad2s4pa3hr4vfa8u...@4ax.com> Alphonse Q
>>Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>>
>>>On Tue, 17 Mar 2009 18:25:26 -0400, Yousuf Khan <bbb...@yahoo.com> wrote:
>>>
>>>>Virtualization will for example let you run Linux
>>>>under Windows, or vice-versa.
>>>
>>>You might wanna review good descriptions of:
>>>
>>>1.) Virtualization and VM's.
>>>2.) Emulation.
>>
>>The problem is that most modern virtual machine solutions are a mix of
>>virtualization and emulation, so the difference between the two concepts
>>is less well defined in practice.
>
>That's certainly news to me.
>
>Can you substantiate?
Yes. In the case of VMWare, it looks something like this:
Emulated :
* Video Card (VMware SVGA II)
* Intel 440BX motherboard chipset
* AMD PCNET Family Ethernet PCI card
* CreativeSound Blaster Audio PCI
Virtualized :
* Processor
* Memory
* SCSI peripherals
* IDE disk (more or less)
Nate Edel
VT also lets you run mismatched bittedness on VMWare workstation - ie a 32
bit guest on a 64 bit host OS, or vice versa. It's worth having for a
developer box if you plan to use VMWare workstation.
--
Nate Edel http://www.cubiclehermit.com/
preferred email |
is "nate" at the | "I do have a cause, though. It's obscenity. I'm
posting domain | for it."
Nate Edel
> Is it an absolute given that I *won't* be able to run *any* sort of
> virtualization if I don't have this VT?
No. It definitely works without it.
> If I have 64-bit XP installed on this machine, and I want to run a
> virtual 32-bit XP session, or even a virtual win-98 session, I won't be
> able?
The opposite (64-bit guest on 32-bit host) definitely will not work without
VT. I'm not sure about the 32-bit guest on 64-bit host, but even if it
works, VT will give a substantial performance boost.
Alphonse Q Muthafuyer
>>>The problem is that most modern virtual machine solutions are a mix of
>>>virtualization and emulation, so the difference between the two concepts
>>>is less well defined in practice.
>>
>>That's certainly news to me.
>>
>>Can you substantiate?
>
>Yes. In the case of VMWare, it looks something like this:
>
>Emulated :
> * Video Card (VMware SVGA II)
> * Intel 440BX motherboard chipset
> * AMD PCNET Family Ethernet PCI card
> * CreativeSound Blaster Audio PCI
Which VMWare product?
Does ESX Server running on "bare metal" with no "guests", do such emulation?
Why 440BX?
DevilsPGD
Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>On Fri, 20 Mar 2009 00:34:57 -0700, DevilsPGD <Death...@crazyhat.net> wrote:
>
>>>>The problem is that most modern virtual machine solutions are a mix of
>>>>virtualization and emulation, so the difference between the two concepts
>>>>is less well defined in practice.
>>>
>>>That's certainly news to me.
>>>
>>>Can you substantiate?
>>
>>Yes. In the case of VMWare, it looks something like this:
>>
>>Emulated :
>> * Video Card (VMware SVGA II)
>> * Intel 440BX motherboard chipset
>> * AMD PCNET Family Ethernet PCI card
>> * CreativeSound Blaster Audio PCI
>
>Which VMWare product?
As far as I know, all of them. The products are essentially the same
from the guest's point of view, although things like sound and USB may
not exist in all products.
>Does ESX Server running on "bare metal" with no "guests", do such emulation?
With no guests? Without a guest OS ESX Server isn't particularly
useful, but without any guest OS running then it wouldn't be emulating
anything, no.
>Why 440BX?
You'd have to ask VMWare, although I'd guess it's likely due to it's
compatibility and relative ease of emulating it. Virtual PC emulates
the same chipset.
Alphonse Q Muthafuyer
>In message <6ahis4pdubfmk4oik...@4ax.com> Alphonse Q
>Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>
>>On Fri, 20 Mar 2009 00:34:57 -0700, DevilsPGD <Death...@crazyhat.net> wrote:
>>
>>>>>The problem is that most modern virtual machine solutions are a mix of
>>>>>virtualization and emulation, so the difference between the two concepts
>>>>>is less well defined in practice.
>>>>
>>>>That's certainly news to me.
>>>>
>>>>Can you substantiate?
>>>
>>>Yes. In the case of VMWare, it looks something like this:
>>>
>>>Emulated :
>>> * Video Card (VMware SVGA II)
>>> * Intel 440BX motherboard chipset
>>> * AMD PCNET Family Ethernet PCI card
>>> * CreativeSound Blaster Audio PCI
>>
>>Which VMWare product?
>
>As far as I know, all of them. The products are essentially the same
>from the guest's point of view, although things like sound and USB may
>not exist in all products.
>
>>Does ESX Server running on "bare metal" with no "guests", do such emulation?
>
>With no guests? Without a guest OS ESX Server isn't particularly
>useful,
Except to define/config new VM's?
I have no experience with VMWare. Are you a hands-on VMWare admin or
in close contact with one?
>but without any guest OS running then it wouldn't be emulating
>anything, no.
>
>>Why 440BX?
>
>You'd have to ask VMWare, although I'd guess it's likely due to it's
>compatibility and relative ease of emulating it. Virtual PC emulates
>the same chipset.
I found it curious because 440BX proper (from late 90's) cannot support
numerous newer devices/equipment.
Please to reference:
http://en.wikipedia.org/wiki/VMware
Excerpt:
Core product design
VMware software provides a completely virtualized set of hardware to the guest
operating system. VMware software virtualizes the hardware for a video
adapter, a network adapter, and hard disk adapters. The host provides pass-
through drivers for guest USB, serial, and parallel devices
1.) Is this accurate?
2.) Is it 100% consistent with what you say re emulation?
Thanks,
DevilsPGD
Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>On Tue, 24 Mar 2009 16:29:25 -0700, DevilsPGD <Death...@crazyhat.net> wrote:
>
>>In message <6ahis4pdubfmk4oik...@4ax.com> Alphonse Q
>>Muthafuyer <mutha...@gmail.com> was claimed to have wrote:
>>
>>>On Fri, 20 Mar 2009 00:34:57 -0700, DevilsPGD <Death...@crazyhat.net> wrote:
>>>
>>>>>>The problem is that most modern virtual machine solutions are a mix of
>>>>>>virtualization and emulation, so the difference between the two concepts
>>>>>>is less well defined in practice.
>>>>>
>>>>>That's certainly news to me.
>>>>>
>>>>>Can you substantiate?
>>>>
>>>>Yes. In the case of VMWare, it looks something like this:
>>>>
>>>>Emulated :
>>>> * Video Card (VMware SVGA II)
>>>> * Intel 440BX motherboard chipset
>>>> * AMD PCNET Family Ethernet PCI card
>>>> * CreativeSound Blaster Audio PCI
>>>
>>>Which VMWare product?
>>
>>As far as I know, all of them. The products are essentially the same
>>from the guest's point of view, although things like sound and USB may
>>not exist in all products.
>>
>>>Does ESX Server running on "bare metal" with no "guests", do such emulation?
>>
>>With no guests? Without a guest OS ESX Server isn't particularly
>>useful,
>
>Except to define/config new VM's?
Right, in which case you wouldn't be running "no guests" anymore... So
I'm not really sure if I've understood your question here.
VMWare only virtualizes or emulates anything for the purposes of guests,
even the so-called "bare metal" versions of virtualization products
aren't, they just run on a light weight optimized version of their
chosen kernel, that kernel still sees the real hardware.
>I have no experience with VMWare. Are you a hands-on VMWare admin or
>in close contact with one?
I spend most of my day using VMWare workstation and Hyper-V for managing
a variety of machines ranging from servers to QA test environments.
I did run VMWare server prior to Hyper-V, but Hyper-V's performance won
me over during the Hyper-V beta and I've moved 100% of my server
virtualization over to Hyper-V at this time.
That being said, I'm only running Hyper-V on two pieces of hardware, not
a massive datacenter or anything like that.
>>but without any guest OS running then it wouldn't be emulating
>>anything, no.
>>
>>>Why 440BX?
>>
>>You'd have to ask VMWare, although I'd guess it's likely due to it's
>>compatibility and relative ease of emulating it. Virtual PC emulates
>>the same chipset.
>
>I found it curious because 440BX proper (from late 90's) cannot support
>numerous newer devices/equipment.
While true, such newer devices don't tend to be emulated within the
virtual environment either. More importantly, switching chipsets is a
*huge* undertaking and not something you'd want to be doing on a regular
basis. Aside from being a ground up rewrite of some of the more
difficult components, it would also cause the same issues the physical
world has moving machines from one hardware platform to another, so it
would make the whole concept of building a VMWare machine once and
deploying it painful for those using the newer hardware.
>Please to reference:
>
>http://en.wikipedia.org/wiki/VMware
>
>Excerpt:
>
>Core product design
>VMware software provides a completely virtualized set of hardware to the guest
>operating system. VMware software virtualizes the hardware for a video
>adapter, a network adapter, and hard disk adapters. The host provides pass-
>through drivers for guest USB, serial, and parallel devices
>
>1.) Is this accurate?
>2.) Is it 100% consistent with what you say re emulation?
Things like disk adapters are one of the easiest examples to look at:
The IDE/SCSI controller that exists in the guest environment doesn't
exist in my physical PC, so by definition the adapter itself is emulated
as there isn't a physical device to virtualize.
Networking is entirely emulated by passing packets back and forth
between host and guest, Hyper-V is the first (as far as I know, anyway)
to change this model and they did it by "inventing" a new NIC, one that
doesn't exist in the real world and only exists within Hyper-V guests
(as well as offering a legacy NIC for non-supported OSes, and/or remote
boot/install of supported OSes before Hyper-V's additions are installed)
The line between emulation and virtualization is blurred and I'm not
sure it's totally meaningful.
Alphonse Q Muthafuyer
from http://en.wikipedia.org/wiki/VMware_ESX_Server :
VMware states that the ESX Server product runs on "bare metal".[3] In contrast
to other VMware products, it does not run atop a third-party operating
system[4], but instead includes its own kernel. Up through the current ESX
version 3.5, a Linux kernel is started first[5] and is used to load a variety
of specialized virtualization components, including VMware's 'vmkernel'
component. This previously-booted Linux kernel then becomes the first running
virtual machine and is called the service console. Thus, at normal run-time,
the vmkernel is running on the bare computer and the Linux-based service
console runs as the first virtual machine (and cannot be terminated or
shutdown without shutting down the entire system
>>I have no experience with VMWare. Are you a hands-on VMWare admin or
>>in close contact with one?
>
>I spend most of my day using VMWare workstation and Hyper-V for managing
>a variety of machines ranging from servers to QA test environments.
>
>I did run VMWare server prior to Hyper-V, but Hyper-V's performance won
>me over during the Hyper-V beta and I've moved 100% of my server
>virtualization over to Hyper-V at this time.
Interesting. Any notion why Hyper-V outperformed VMWare?
>That being said, I'm only running Hyper-V on two pieces of hardware, not
>a massive datacenter or anything like that.
>
>>>but without any guest OS running then it wouldn't be emulating
>>>anything, no.
>>>
>>>>Why 440BX?
>>>
>>>You'd have to ask VMWare, although I'd guess it's likely due to it's
>>>compatibility and relative ease of emulating it. Virtual PC emulates
>>>the same chipset.
Well, it's a famous, famous chipset, one of Intels most successful. I
ran it (native, of course) for years on my desktop. Still have >= 1
mobo in the basement ...
>>I found it curious because 440BX proper (from late 90's) cannot support
>>numerous newer devices/equipment.
>
>While true, such newer devices don't tend to be emulated within the
>virtual environment either. More importantly, switching chipsets is a
>*huge* undertaking and not something you'd want to be doing on a regular
>basis. Aside from being a ground up rewrite of some of the more
>difficult components, it would also cause the same issues the physical
>world has moving machines from one hardware platform to another, so it
>would make the whole concept of building a VMWare machine once and
>deploying it painful for those using the newer hardware.
One difficulty I have with virtualization is that, when they move beyond
the "simple case", the semantics can really get tricky. To run numerous
VM's on one box is one thing. To be able to *move* VM's, say, from a
newer box to the *newest* box can be quite another. I'm finding that
some features of x86 virtualization are oriented to this type of thing
(a new concept to me).
Back to 440BX:
http://www.intel.com/design/chipsets/440bx/index.htm
Intel® 440BX AGPset Package Information
Product Package
82443BX AGP Host Bridge Controller 492 Ball Grid Array (BGA)
82371AB PCI-ISA Bridge 324 Ball Grid Array (BGA)
The 440BX 82443BX (North Bridge) Memory Controller is emulated by VMWare
guests?
>>Please to reference:
>>
>>http://en.wikipedia.org/wiki/VMware
>>
>>Excerpt:
>>
>>Core product design
>>VMware software provides a completely virtualized set of hardware to the guest
>>operating system. VMware software virtualizes the hardware for a video
>>adapter, a network adapter, and hard disk adapters. The host provides pass-
>>through drivers for guest USB, serial, and parallel devices
>>
>>1.) Is this accurate?
>>2.) Is it 100% consistent with what you say re emulation?
>
>Things like disk adapters are one of the easiest examples to look at:
>The IDE/SCSI controller that exists in the guest environment doesn't
>exist in my physical PC, so by definition the adapter itself is emulated
>as there isn't a physical device to virtualize.
That's hard to follow if taken literally. The physical IDE/SCSI controllers
*have* to exist on the hardware platform. Whether or not they can be
virtualized for a guest OS is another issue.
>Networking is entirely emulated by passing packets back and forth
>between host and guest, Hyper-V is the first (as far as I know, anyway)
>to change this model and they did it by "inventing" a new NIC, one that
>doesn't exist in the real world and only exists within Hyper-V guests
>(as well as offering a legacy NIC for non-supported OSes, and/or remote
>boot/install of supported OSes before Hyper-V's additions are installed)
Your Hyper-V runs under Win Server '08? Could you briefly describe
the software build for such a box?
>The line between emulation and virtualization is blurred and I'm not
>sure it's totally meaningful.
Until certain types of performance bottlenecks rear their ugly heads?
Well, I gotta ask. To what extent do you think x86 virtualization
(i.e. with VMWare) is all about:
a.) Writing hypervisor drivers etc for native support of newer hardware.
b.) Writing translation-drivers for guest OS's so the guest thinks
it is running XX while the hypervisor is translating or interpreting
it into YY?
I might've been coding JCL back around '84 when a knowledgable person
told me that my MVS was running as a guest under (IBM) VM. I have taken
virtualization seriously ever since. :-) Not that I know that much
about the nuts and bolts. Am now 9 years retired from the industry.
Of course, it's the hottest thing on the bleeding edge. Virtualize the
servers. Virtualize the desktops. Virtualize the net. Virtualize the
storage. Add some stuff like iSCSI and Fiber Channel over 10GB Ethernet,
and it's a Brave New World all over again. But, lordy me, the semantics!
Or maybe I'm just reading the wrong stuff.
Bill Davidsen
Virtualization solves the problem of wanting to upgrade to a new OS version but
knowing it still has some kinks, or running the latest version but keeping an
old OS in a VM because it has something no longer supported but lacks the latest
security features.
I'm typing from a VM I use as my desktop, since I can move the image to any
similar machine and run it there. At one time it was a 1998 version of Linux,
running safely in a VM. I have XP and Win7 VMs as well, and a few small servers
which can just be moved to another machine at will.
Robert Myers
I had a really hard time visualizing a VM until I actually used one.
Now things are much more clear, and, while I still don't understand
the virtue of running 100 Linux servers on a mainframe, I can see some
definite advantages for me:
I can run Linux as a guest on Windows and have access to both
environments at the same time.
I'm assuming that it's the VT-x technology that allows me to run the
virtual Linux box with it's own IP address. My router sees two
distinct computers, in spite of the fact that I have but one ethernet
card. I can ssh into the guest Linux box from the host box and use
sftp to move files back and forth between the two machines.
I'm running the guest Linux on vmware player. All my devices are
visible to the guest box, although I haven't tried using some of them.
I've already used blank virtual machines as crash and burn boxes. I
really like being able to do that.
A couple of Intel documents have been helpful to me in understanding
just what it is that VT-x can do
http://www.intel.com/technology/itj/2006/v10i3/1-hardware/8-virtualization-future.htm
http://download.intel.com/technology/itj/2006/v10i3/v10-i3-art01.pdf
and the advantages seem to be substantial. It also seems clear that
you don't *need* it, as is obvious from your own history. I have
esxi, but that's a different level I have yet to try. The possibility
of running on nearly bare iron is pretty attractive.
Robert.
Yousuf Khan
> I had a really hard time visualizing a VM until I actually used one.
> Now things are much more clear, and, while I still don't understand
> the virtue of running 100 Linux servers on a mainframe, I can see some
> definite advantages for me:
>
> I can run Linux as a guest on Windows and have access to both
> environments at the same time.
>
> I'm assuming that it's the VT-x technology that allows me to run the
> virtual Linux box with it's own IP address. My router sees two
> distinct computers, in spite of the fact that I have but one ethernet
> card. I can ssh into the guest Linux box from the host box and use
> sftp to move files back and forth between the two machines.
The virtualized network interfaces actually predates the virtualized
processor environments by many years, and it's not really achieved
through the virtual processor mechanisms, nor is processor
virtualization necessary. It's simply a matter of changing the MAC ID of
the packets. Usually the MAC ID is whatever is built into the firmware
of the network adapter, or sometimes even into the BIOS firmware of the
host machine. But this identifier is interceptable and changeable.
Prior to processor virtualization, I used to run Sun machines with
multiple websites, each website was assigned its own virtual network
interface and was thus easily routable by MAC ID alone.
Yousuf Khan
Robert Myers
>
> The virtualized network interfaces actually predates the virtualized
> processor environments by many years, and it's not really achieved
> through the virtual processor mechanisms, nor is processor
> virtualization necessary. It's simply a matter of changing the MAC ID of
> the packets. Usually the MAC ID is whatever is built into the firmware
> of the network adapter, or sometimes even into the BIOS firmware of the
> host machine. But this identifier is interceptable and changeable.
>
> Prior to processor virtualization, I used to run Sun machines with
> multiple websites, each website was assigned its own virtual network
> interface and was thus easily routable by MAC ID alone.
>
I mentioned it mostly because the machine can talk to itself without
the intervention of a third party. For me, it's very convenient
because I don't have to worry so much about which environment
something is in.
Mostly, I was always aware of the privileged instruction issue and, no
matter whether it could be gotten around or not without VT-x, it
always sounded like it had to be baling wire and chewing gum, and I
had no interest in experimenting. That is to say, whether it's
supposed to work or not, I wouldn't bother with virtualization without
explicit hardware support for it because of the issues with
virtualization and x86. Good for vmware that they could work around
it; it wasn't worth any kind of risk for me. Now that it's well-
supported and can be had for free, it's pretty nifty.
Robert.
j...@cix.compulink.co.uk
<9aeb629c-d9d1-43fa...@r34g2000vba.googlegroups.com>,
rbmye...@gmail.com (Robert Myers) wrote:
> ... while I still don't understand the virtue of running 100 Linux
> servers on a mainframe
One of the major advantages, from the PoV of IBM, and of the people in
their customers who have built their careers round mainframes, is that
it provides a new reason for having a mainframe.
It can also take up less space and consume less power, and so on, but
that depends on how hard your "Linux machines" are being worked, and
what the other pressures on the organisation are.
As an example, my employers have a whole lot of PCs, running Windows or
Linux, running overnight each night testing the day's changes to
CPU-bound software. We use the developer's desktops for this overnight,
as well as lots of other machines. Notably, when a developer's desktop
finishes its three-year depreciation life, it goes into the test farm,
and does another 2-4 years there, depending on how fast it goes obsolete
or breaks down.
Some corporate IT management types have been trying to convince us to
buy blade servers for the test farm. They claim it will save money, but
we can't see how and they can't demonstrate it. We have enough space for
the old machines. While we could cram the same CPU power into less space
with blade servers, we have no other use for the space unless we are
allowed to hire some more people. Blade servers, like mainframes, are a
more expensive way of getting the same CPU power than ordinary desktops
bought on a bulk purchase deal.
--
John Dallman j...@cix.co.uk
"C++ - the FORTRAN of the early 21st century."
Robert Myers
> In article
> <9aeb629c-d9d1-43fa-9097-e069330c2...@r34g2000vba.googlegroups.com>,
>
> rbmyers...@gmail.com (Robert Myers) wrote:
> > ... while I still don't understand the virtue of running 100 Linux
> > servers on a mainframe
>
> One of the major advantages, from the PoV of IBM, and of the people in
> their customers who have built their careers round mainframes, is that
> it provides a new reason for having a mainframe.
>
> It can also take up less space and consume less power, and so on, but
> that depends on how hard your "Linux machines" are being worked, and
> what the other pressures on the organisation are.
>
few genuine advantages of mainframes: they are usually not an
attractive target for hacking. If you virtualize Linux on them, the
only advantage you have left is that it's not x86, which advantage you
can get from other platforms (even and perhaps most compellingly
Itanium) at a much lower price.
Mainframes like to stay busy (translation: if your mainframes aren't
busy, you're burning big money), and aggregating lots of servers is
one plausible way of keeping any computer running servers, which spend
much of their time waiting, busy. I assume that the sales folks at
IBM have the pricing worked out (the same hardware is much cheaper if
it runs Linux) so they can make the case with a straight face, but
Itanium running HP-UX still sounds pretty attractive by comparison.
Not my side of the universe, anyway.
For people running lots of servers, the need for virtualization is
obvious and hardware support on x86 is a no-brainer if you're not
trying to protect Itanium, as Intel no longer is. For the rest of us,
it looks like a neat way to build sandboxes very cleanly.
> As an example, my employers have a whole lot of PCs, running Windows or
> Linux, running overnight each night testing the day's changes to
> CPU-bound software. We use the developer's desktops for this overnight,
> as well as lots of other machines. Notably, when a developer's desktop
> finishes its three-year depreciation life, it goes into the test farm,
> and does another 2-4 years there, depending on how fast it goes obsolete
> or breaks down.
>
> Some corporate IT management types have been trying to convince us to
> buy blade servers for the test farm. They claim it will save money, but
> we can't see how and they can't demonstrate it. We have enough space for
> the old machines. While we could cram the same CPU power into less space
> with blade servers, we have no other use for the space unless we are
> allowed to hire some more people. Blade servers, like mainframes, are a
> more expensive way of getting the same CPU power than ordinary desktops
> bought on a bulk purchase deal.
>
Nothing about blade servers makes sense to me except that they are
cute and are more readily adapted for telcos.
I have yet to see the TCO argument about older PC's settled
definitively. Most calculations I've seen indicated, a few years ago
at least, that computers aged out of being cost effective for compute-
intensive operations after about three years. After that, you were
better off buying new than continuing to pay for electricity to run
obsolete equipment. Where the break-point is depends on the cost of
electricity, obviously. It also depends on the time derivatives of
watts/flop, of new-hardware-$/flop and of the cost of electricity.
From the POV of a departmental budget, though, maybe you don't care
about the cost of electricity.
Robert.
j...@cix.compulink.co.uk
<54245063-9c1c-48f0...@g6g2000vbr.googlegroups.com>,
rbmye...@gmail.com (Robert Myers) wrote:
> From the POV of a departmental budget, though, maybe you don't care
> about the cost of electricity.
Yup: it's a site overhead, rather than a departmental thing. Maybe it
should be departmental, but getting the finance people to organise
things so that we can make the trade-offs at budgeting time could be
hard.
When you testing isn't one huge pool, but lots of separate things, such
as several different customers' apps being run with new versions of the
libraries we produce, using the customers' test sets, using separate
machines for each test set can be a hell of a lot easier to organise.
Our usage of additional CPU cores is also rather less than perfectly
efficient, which tends to reduce the CPU/watt advantages of newer
machines.