| Author |
Message |
Ketil Malde
Guest
|
 Posted:
Wed Feb 09, 2005 7:57 am Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
| Quote: | On Tue, 08 Feb 2005 15:05:07 -0600, Anton Rang wrote:
Well, some customers have needs (or at least a desire) for:
(a) Running more than one OS, or more than one version of the OS,
on the same hardware.
However practical a reason (and I admit that it is one) that sounds like a
failure of OSes, in particular a failure of inter-operating system
standardisation.
|
Yes of course. But convincing MS to port all their libraries to
Linux, just so you can run <favorite application> is hard.
| Quote: | (b) Providing a full OS environment to clients. Maybe the client
wants the ability to manage their own system (install their own
software, potentially add new kernel modules, etc). If you have
hardware VM, you can let a client install their own OS, reboot,
give them root access, etc.
That sounds like a particular business model based around virtualization.
Fair enough. If your clients just want to be able to install programs and
be root on a shared box, then there are operating systems that support
that (vis jails on FreeBSD and chroot environments (a lower standard of
protection) on other unices, or perhaps user-mode linux).
|
I would argue that UML *is* virtualization, although without hardware
support. UML also has a bit of overhead, which, presumably, hw
virtualization would do away with.
| Quote: | (c) Testing a new software release. As in the case of running
more than one OS, you can get by without having to buy and manage
another machine.
That's kind of neat, but if you're testing, then you may well want more
diagnostics of the sort that simulation can provide, rather than simple
virtualization. In any case, software developers wouldn't seem to be a
large enough community to support this sort of feature on their own.
|
The way I interpreted this, it isn't as much for developers as for
systems administrators. It's fairly common to have separate boxes for
the specific purpose of testing out new software before deployment.
It'd be nice to be able to test it out on the real target (which may
be expensive enough that you don't want to buy more than you need),
without affecting the old system.
| Quote: | (d) Isolating customers from each other. The typical OS can
do this for ordinary users, but not administrators.
To the extent that that sort of facility doesn't exist (see jails: it
does), then that would be a failing of the OSes in question, for that
application.
|
What if you have a bunch of students hacking the kernel?
| Quote: | Didn't the PC revolution do away with that time-sharing model anyway, and
give all users root access of the box that they were using?
|
I love you. Melissa. Code Red. Guess you're right. :-)
| Quote: | I'm sure there are other ideas for how this would be used.
I'm sure there are.
|
Real-time Linux. Since it's apparently hard to get RT performance
from Linux, while at the same time it's nice to have a full, POSIX
compliant, multi-user system, the (one of the) solution(s) is to run a
small RT system *in addition to* the full Linux system.
(You could argue that this is in the "failing of current OSes"
category, but sometimes, simplicity is what you need, and you can't
really "add" simplicity to a complex system.)
Shared computer facilities. When a (large and expensive) computer is
shared between departments (say) there's always a question of security
and fairness. Often, access becomes more cumbersome. Wouldn't it be
nice if the departments could access separate virtualized machines,
running securely with their home environment available and whatever
software, also on the system level, that each department needed?
This, or something similar, seems to be fairly common in business
computing, and I guess it has been since the sixties or so. One can
only hope the HPC community one day will look up from their Fortran
code and catch up some of the 40 years they're lagging behind...
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants |
|
| Back to top |
|
 |
Alex Colvin
Guest
|
| Posted:
Wed Feb 09, 2005 2:30 pm Post subject:
Re: Cell press release, redacted. |
|
|
| Quote: | slightly reminiscent of the CDC 6600 with its IOPs, but viceversa (a
central IO processor with peripheral vector processors). I guess it is
like CPU + 8 x (AltiVec + RAM each).
|
Might make a good CM-2
--
mac the naïf |
|
| Back to top |
|
|
Torben Ægidius Mogensen
Guest
|
| Posted:
Wed Feb 09, 2005 2:30 pm Post subject:
Re: cell programming model |
|
|
kirk johnson <tunaNO@SPAMindra.com> writes:
| Quote: | so what kind of a programming model will cell present at the ISA
level? will the "attached cores" effectively be independent CPUs that
interact with the primary CPU in something approximating standard
threading models? or, alternately, will the "attached cores" look more
like coprocessors that are controlled directly by the primary CPU? or
perhaps something in between (e.g., coprocessor-like, but with the
primary CPU able to dispatch fairly high semantic content
"instructions" instead of individual floating point ops).
|
From the limited information I have seen, I think they are most like a
8-wide vector coprocessor, but with possibility of splitting it into
several smaller vectors with separate instructions.
| Quote: | pushing things up to a higher level, what's the consensus about
programming language/compiler support for such a beast? do we expect
that compilers will be able to automatically extract sufficient
parallelism from nominally-sequential programs to take advantage of
all those "attached cores"? or, alternately, do we expect that
hand-coding and/or well-tuned libraries will be needed to achieve
significant performance gains?
|
You can probally extract parallelism for some types of code, e.g.,
"Fortran-like" code consisting of loops that operate over arrays. But
I doubt you will get much from average C code. Initially, I think you
will have to rely on hand-coded libraries to get anywhere near full
utilisation. But for games machines, this is the usual case anyway.
Torben |
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted:
Wed Feb 09, 2005 4:22 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
On Wed, 09 Feb 2005 17:12:22 +1100, Andrew Reilly <andrew-newspost@areilly.bpc-users.org> wrote:
| Quote: | On Wed, 09 Feb 2005 00:05:13 -0500, Joe Seigh wrote:
[...]
From the software development perspective, too, how sure are you
that your OS won't misbehave when the wall-clock time keeps jumping
forward unexpectedly? What's that going to do to your carefully
tuned thread priorities in your real-time multimedia game/application?
|
The guest machines would have individual virtual clocks which aren't
affected by other guest machines. VM is a time sharing system. You
don't run real time stuff in that environment even on non-VM systems
unless you give the real time guest dedicated resources, to use VM terminology.
[...]
| Quote: |
The efficiency I meant was space efficiency, not (necessarily)
access time efficiency. Real OSes let applications share disk space
at the file and sector level (or even finer), not just at the volume
or partition level. You could achieve this between VM client
instances with something like a SAN cluster FS and a distributed
lock manager, but I don't know if any of those work across different
operating systems.
|
I'm having a hard time following you since I don't see how virtual
disk abstraction is different from any other form of disk storage
abstraction layers in use today.
--
Joe Seigh
Lock-free synchronization primitives
http://atomic-ptr-plus.sourceforge.net/ |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Wed Feb 09, 2005 5:29 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
In article <pan.2005.02.08.23.55.39.59408@areilly.bpc-users.org>,
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
|> On Tue, 08 Feb 2005 15:05:07 -0600, Anton Rang wrote:
|>
|> > (a) Running more than one OS, or more than one version of the OS,
|> > on the same hardware. Maybe you have software that requires
|> > Windows 98 or Solaris 6. No need to keep a separate box for
|> > this one application. This also works for software which
|> > wants to be installed in a particular location.
|>
|> However practical a reason (and I admit that it is one) that sounds like a
|> failure of OSes, in particular a failure of inter-operating system
|> standardisation. I guess that consumer pressure just hasn't managed to
|> mandate that yet, despite initiatives like POSIX. ...
Firstly, POSIX was and is primarily to define interfaces for
unprivileged applications, and secondarily to provide ones for
slightly privileged system utilities. I don't think that even
any of its aborted projects tackled the issues of standardising
interfaces for the implementation of complete operating systems.
Let's skip a discussion of whether it tackled its objectives as
well as it could have done, though some aspects of that are
relevant.
Secondly, you can implement features only if you have access to
appropriate primitives, as I have pointed out ad tedium. If the
hardware does not provide adequate primitives for virtualisation
(and most don't), then no operating system can provide it. That
does not mean that hardware should ALWAYS provide it, as it
imposes significant constraints and you can oftne get most of
the gain by providing primitives for partial virtualisation (e.g.
Solaris Zones).
|> Didn't the PC revolution do away with that time-sharing model anyway, and
|> give all users root access of the box that they were using?
Are you serious, or trolling? Obviously not, except in the hacker
community.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Peter Grandi
Guest
|
| Posted:
Wed Feb 09, 2005 5:40 pm Post subject:
Re: Cell press release, redacted. |
|
|
[ ... ]
| Quote: | Another advantage of Cell is to support multiple operating systems,
such as conventional operating systems (including Linux), real-time
operating systems for computer entertainment and consumer electronics
applications as well as guest operating systems for specific
applications, simultaneously.
|
foo> I just came out of the SPE session, and I have to say that I don't
foo> know what this paragraph above means. [ ... ]
foo> There's a 64b PPC processor, in order, dual threaded, and that's
foo> the master CPU, so you can run any OS you want, but the SPE's
foo> aren't "real CPUs", as far as what we generally want in a "real
foo> CPU" these days. Specifically, quoting directly from the ISSCC
foo> paper on the SPE's, it states
foo> . . . "The focus on efficiency comes at the cost of multi-user
foo> operating system support. SPE load and store operations are
foo> performed within a local address space, not in system address
foo> space." . . .
foo> I am befuddled.
It looks like just a scaling up of the PS2 EE architecture: a little CPU
runs the main control thread, a number of SIMD-style coprocessors (now
called SPEs instead of VUs) with tiny local memory chug away; perhaps
slightly reminiscent of the CDC 6600 with its IOPs, but viceversa (a
central IO processor with peripheral vector processors). I guess it is
like CPU + 8 x (AltiVec + RAM each).
As usual, and as noted in other recent articles in comp.arch, the big
problem is memory bandwidth; since the problem is insoluble at the sort
of cost that can be budgeted for a console, the workaround is to require
programmers to manually split up apps in up to 9 sections, a ``control''
one and up to 8 running on a very fast SIMD CPU with a an equally fast,
but tiny, local memory.
To me it is designed to support procedural data generation, just like
the PS2 EE, only much more so. If you know about the ``demoscene''
<URL:http://WWW.Scene.org/>, it looks like one CPU plus eight
``demoscene'' processors...
As to the «multiple operating systems, [ ... ] simultaneously» that
simply means that the CPU has got virtualization abilities. Is that new
for the PPC line? I doubt it, but even if it is new for PPC, nothing
special, it is a standard IBM thing.
My guess is that the SPEs (the ``demoscene'' processors) don't have it,
so they are probably to be allocated to the ``virtual machines'' more or
less statically, or perhaps on request.
Something like perhaps none to the Linux virtual machine that runs the
GUI, one or two (e.g. decoding and rescaling) to the DVD-playing virtual
machine, and the rest to the game virtual machine.
As to the advantages of virtualization, also consider DRM issues... |
|
| Back to top |
|
|
Andrew Reilly
Guest
|
| Posted:
Wed Feb 09, 2005 6:18 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
On Wed, 09 Feb 2005 13:29:15 +0000, Nick Maclaren wrote:
| Quote: |
In article <pan.2005.02.08.23.55.39.59408@areilly.bpc-users.org>,
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
|> On Tue, 08 Feb 2005 15:05:07 -0600, Anton Rang wrote:
|
|> > (a) Running more than one OS, or more than one version of the OS,
|> > on the same hardware. Maybe you have software that requires
|> > Windows 98 or Solaris 6. No need to keep a separate box for
|> > this one application. This also works for software which
|> > wants to be installed in a particular location.
|
|> However practical a reason (and I admit that it is one) that sounds like a
|> failure of OSes, in particular a failure of inter-operating system
|> standardisation. I guess that consumer pressure just hasn't managed to
|> mandate that yet, despite initiatives like POSIX. ...
Firstly, POSIX was and is primarily to define interfaces for
unprivileged applications, and secondarily to provide ones for
slightly privileged system utilities.
|
Yep. Pity it hasn't worked out (yet). Maybe java will get there instead.
| Quote: | I don't think that even
any of its aborted projects tackled the issues of standardising
interfaces for the implementation of complete operating systems.
|
Of course not. That's a daft notion.
More specifically, why would that be a useful goal? The point of the
exercise is to run applications. The OS is merely a means to the specific
end of running more than one application on any given piece of hardware,
and perhaps being able to run the same application on different pieces of
hardware.
| Quote: | Secondly, you can implement features only if you have access t8o
appropriate primitives, as I have pointed out ad tedium. If the
hardware does not provide adequate primitives for virtualisation
(and most don't), then no operating system can provide it. That
does not mean that hardware should ALWAYS provide it, as it
imposes significant constraints and you can oftne get most of
the gain by providing primitives for partial virtualisation (e.g.
Solaris Zones).
|> Didn't the PC revolution do away with that time-sharing model anyway, and
|> give all users root access of the box that they were using?
Are you serious, or trolling? Obviously not, except in the hacker
community.
|
The quoted text was a reply to the (hypothetial) situation of wanting to
allow students root access so that they could learn system administration.
I thought that the contemporary approach was to just give them all PCs
(crash-boxes by any other name) and let them have at it. In the famous
words of Andy Glew: what's different now? Why is it suddenly more
interesting or economical to have them all trying to share a single, large
box, as it was in the 60s and 70s? If that's really the game, then bring
on Multics, by all means. Just don't muck about with this half-arsed VM
nonsense. I just don't believe that the PC revolution is so easily spent.
More than one CPU per user, please. They're only a few bucks.
--
Andrew |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Wed Feb 09, 2005 6:39 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
In article <pan.2005.02.09.13.18.34.944367@areilly.bpc-users.org>,
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
|> >
|> > Firstly, POSIX was and is primarily to define interfaces for
|> > unprivileged applications, and secondarily to provide ones for
|> > slightly privileged system utilities.
|>
|> Yep. Pity it hasn't worked out (yet). Maybe java will get there instead.
And maybe the future of air transport is by pig.
|> > I don't think that even
|> > any of its aborted projects tackled the issues of standardising
|> > interfaces for the implementation of complete operating systems.
|>
|> Of course not. That's a daft notion.
|>
|> More specifically, why would that be a useful goal? The point of the
|> exercise is to run applications. The OS is merely a means to the specific
|> end of running more than one application on any given piece of hardware,
|> and perhaps being able to run the same application on different pieces of
|> hardware.
Might someone not find it useful to be able to run the same operating
system on new hardware - without having to rewrite it?
Would it surprise you to know that several major vendors and vendor
consortia have several times tackled precisely this objective for
precisely that reason?
|> The quoted text was a reply to the (hypothetial) situation of wanting to
|> allow students root access so that they could learn system administration.
|> I thought that the contemporary approach was to just give them all PCs
|> (crash-boxes by any other name) and let them have at it. In the famous
|> words of Andy Glew: what's different now? Why is it suddenly more
|> interesting or economical to have them all trying to share a single, large
|> box, as it was in the 60s and 70s? If that's really the game, then bring
|> on Multics, by all means. Just don't muck about with this half-arsed VM
|> nonsense. I just don't believe that the PC revolution is so easily spent.
|> More than one CPU per user, please. They're only a few bucks.
A) As experience would tell you, a lot of errors at the kernel end up
with a dead system and no diagnostics. A good VM system will allow
you to get into that system in the same way that a good debugger
allows you to get into a dead application. VERY useful.
B) A good VM system allows for approximate testing of one configuration
on another. This is almost essential if you don't want to have a huge
number of testing machines, multiplied by the size of your class. It
is even more important for commercial testing, of course.
C) Related to the first point, a good VM system will reduce the number
of times that you have to physically go to the machine to reset it or,
worse, reinstall firmware or, even worse, replace irredeemably broken
hardware. Yes, a student CAN corrupt firmware so badly that the only
solution is to replace the device.
All of these advantages were known before 1970, though the last was
regarded as a misdesign in the system. It isn't now :-(
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
kirk johnson
Guest
|
| Posted:
Wed Feb 09, 2005 7:50 pm Post subject:
Re: cell programming model |
|
|
KJ = kirk johnson
TM = torbenm@diku.dk (torben ægidius mogensen)
JW = jason watkins (comp.arch, 9 jan 2003)
KJ > so what kind of a programming model will cell present at the ISA
| Quote: | level? will the "attached cores" effectively be independent CPUs
that interact with the primary CPU in something approximating
standard threading models? or, alternately, will the "attached
cores" look more like coprocessors that are controlled directly
by the primary CPU? or perhaps something in between (e.g.,
coprocessor-like, but with the primary CPU able to dispatch
fairly high semantic content "instructions" instead of
individual floating point ops).
|
TM > From the limited information I have seen, I think they are most
| Quote: | like a 8-wide vector coprocessor, but with possibility of
splitting it into several smaller vectors with separate
instructions.
|
but this doesn't answer the question of how the vector units are
"controlled" by the primary CPU. i did find one item in the
comp.arch-ives (citation above) that made some speculations based on
reading of patents:
JW > In the cell processor, each packet has a series of DMA
| Quote: | instructions that loads from the global shared memory to each
subprocessor's local memory. These set up the environment and
stack frame. Once these have completed each subprocessor begins
execution of the packet's code.
The memory consistancy model is harsh: reads to global memory
lock a given memory location. An additional read will block
until the first reader writes. It's not explicitly mentioned
what happens in the face of more than a 2nd read.
So given this model, packets must be fairly long term in
nature. For a streaming workload, this is simple... after all,
the kernels tend to be small and aside from the streaming data
would have just constants, lookup tables and the like. I also
assume that there is some sort of copy instruction, so that such
constant data can be read from global memory to local memory
without locking.
|
so this sounds more like a model in which the vector units aren't
really fully-independent CPUs, but can execute autonomously for at
least modest periods of time (via packets of instructions that are
dispatched to them by the primary CPU). this is all speculation, of
course.
KJ > pushing things up to a higher level, what's the consensus about
| Quote: | programming language/compiler support for such a beast? do we
expect that compilers will be able to automatically extract
sufficient parallelism from nominally-sequential programs to
take advantage of all those "attached cores"? or, alternately,
do we expect that hand-coding and/or well-tuned libraries will
be needed to achieve significant performance gains?
|
TM > You can probally extract parallelism for some types of code,
| Quote: | e.g., "Fortran-like" code consisting of loops that operate over
arrays. But I doubt you will get much from average C code.
Initially, I think you will have to rely on hand-coded libraries
to get anywhere near full utilisation. But for games machines,
this is the usual case anyway.
|
strong agreement.
very interesting stuff. will be interesting to see how it all shakes
out.
kirk |
|
| Back to top |
|
|
Casper H.S. Dik
Guest
|
| Posted:
Wed Feb 09, 2005 9:10 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
| Quote: | There's no reason why modern Windows shouldn't be able to support
Windows 98 (or earlier) applications, or for Solaris 10 to support Solaris
6 (or even SunOS-4) applications, since in both cases the companies own
all of the necessary library copyrights.
|
Solaris 10 does exactly that, but:
- ISVs are often not willing to support programs other than on
"certified" releases.
- Their be dragons: even perfect compatibility will not allow
all programs to run because programs have bugs in them.
Some of those bugs proof fatal in new OS releases and are
impossible to fix.
The only way to guarantee 100% compatibility is not making changes;
there's no way to fend off incompatibilities introduced by applications
which
use known unportable constructs:
- abuse system reserved global registers
- assume they can use certain mappings
rely on the OS forgiving certain bugs (without realizing this)
- uninitialized stack variables which just happen to get
the right values
- writing one past the end of a buffer
- freeing something twice
- ....
Providing compatability with all that is just impossible or
uneconomical; over the past 15 years I have seen many examples of the
second category.
| Quote: | Didn't the PC revolution do away with that time-sharing model anyway, and
give all users root access of the box that they were using?
|
I think there's no large organization in the world that doesn't want
to get rid of the PC desktop which isn't under strict control.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth. |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Wed Feb 09, 2005 10:04 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
| Quote: | C) Related to the first point, a good VM system will reduce the
number of times that you have to physically go to the machine to
reset it or, worse, reinstall firmware or, even worse, replace
irredeemably broken hardware. Yes, a student CAN corrupt firmware
so badly that the only solution is to replace the device.
All of these advantages were known before 1970, though the last was
regarded as a misdesign in the system. It isn't now :-(
|
almost. the 370 virtual memory architecture came out long before there
was actually hardware built for it ... and it had numerous differences
(table formats, instruction op code, etc) from the implementation in
the 370/67. so a joint project was started between endicott (building
370/145) and science center (originated cp67) to create a special kind
of virtual machine under cp67 that simulated 370 virtual memory
virtual machines (as opposed to simulated 360 virtual machines).
so this was one of the first major production uses of the internal
network software ... also developed at the science center.
after there was cp67 kernel that had the support for 370 virtual
machines, then another set of modifications were made to cp67 ... so
that it the kernel would conform to 370 relocate tables and
instructions (rather than 360).
now science center had a problem ... it was providing semi-open
time-sharing access to non-corporate employees (mit, bu, harvard, etc
students). it was also hosting some extended APL access by people from
corporate hdqtrs that had loaded the most sensitive and most highly
classified corporate data on the machine for doing business modeling
and what-ifs (in the era, apl was used for a lot of the stuff that
spreadsheets are now used for).
in any case there was an issue if the cp67 kernel that provided
virtual 370 machines was run on the bare hardware ... there might be
some of the area students stumble across the features (and they were
trying to fairly tightly control the secret of virtual memory for
370). in any case,
cp67-l kernel was run on bare hardware providing general computing
access
cp67-h kernel was run in a 360/67 virtual machine and it provided
370 virtual machines
cp67-i kernel was run in a 370 (virutal memory) virtual machine
cms was run in a 370 virtual machine
so that has been running for something like a year. endicott engineers
finally claim that they have an 370/145 with engineering changes to
support virtual memory and it is ready for some testing.
some people go to endicott and install a cp67-i kernel and attempt to
boot ... and it fails. so some amount of investigation ... and it
turns out that the kernel is correct ... but the engineers had
reversed the implementation of the "B2" opcodes for PTLB (purge
lookaside table) and RRB (reset reference bit). so some quick patches
in a couple places ... and the kernel boots and runs fine. also
software designed to the architecture spec runs correctly in virtual
machines ... since the virtual machine emulation of the "B2" opcodes
conform to the official architecture ... it is only the real kernel
use of the functions that has been changed to conform to the real
machine.
current description of PTLB
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.30?SHELF=EZ2HW125&DT=19970613131822
you have to settle for current description of RRB-extended:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.31?SHELF=EZ2HW125&DT=19970613131822
part of the difference was that 370 supported both 2kbyte pages and
4kbyte pages ... so RRB operated on 2k blocks of storage. support for
2k byte pages has since been dropped.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Eric P.
Guest
|
| Posted:
Wed Feb 09, 2005 11:04 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
Del Cecchi wrote:
| Quote: |
If you go wander around IBM's web site, I am confident you will find
plenty of information about the virtues of virtualization. It seems to
be a key element of the Server Value Proposition. Or whatever.
|
Looking at
http://www-1.ibm.com/servers/eserver/about/virtualization/
it seems to be mostly concerned with systems management,
and remote management in particular.
These are functions I would prefer, and seem most natural,
located in the OS and accessable via APIs and thereby usable for
many purposes by value added and ISV developed applications.
Eric |
|
| Back to top |
|
|
Eric P.
Guest
|
| Posted:
Wed Feb 09, 2005 11:12 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
Ketil Malde wrote:
| Quote: |
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
On Tue, 08 Feb 2005 15:05:07 -0600, Anton Rang wrote:
Well, some customers have needs (or at least a desire) for:
(a) Running more than one OS, or more than one version of the OS,
on the same hardware.
However practical a reason (and I admit that it is one) that sounds like a
failure of OSes, in particular a failure of inter-operating system
standardisation.
Yes of course. But convincing MS to port all their libraries to
Linux, just so you can run <favorite application> is hard.
|
I would be happy if MS libraries just ported between their own OS
versions. There was no technical reason for dll-hell to occur in the
first place, and I see no reason for it to continue other than sloven.
But one doesn't need VM to solve this.
Eric |
|
| Back to top |
|
|
Eric P.
Guest
|
| Posted:
Wed Feb 09, 2005 11:18 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
Anton Rang wrote:
| Quote: |
"Eric P." <eric_pattison@sympaticoREMOVE.ca> writes:
One question is why would an OS vendor divert funding into
developing a virtualization product rather than applying
those funds to cleaning up the original problems in its code
(the ones the virtualization supposedly addresses)? The answer
appears to be because they get to sell you another product.
Well, some customers have needs (or at least a desire) for:
(a) Running more than one OS, or more than one version of the OS,
on the same hardware. Maybe you have software that requires
Windows 98 or Solaris 6. No need to keep a separate box for
this one application. This also works for software which
wants to be installed in a particular location.
|
I can see this in certain specific situations where it is not
practical to get a second system. This could be due to cpu cost such
as in the days of yor, or a modern 16 cpu Power5 system, or physical
configuration, like all the phone lines run into a single box.
But these look like niche situations.
In general the easiest solution appears to be buy another box.
| Quote: | (b) Providing a full OS environment to clients. Maybe the client
wants the ability to manage their own system (install their
own software, potentially add new kernel modules, etc). If
you have hardware VM, you can let a client install their own
OS, reboot, give them root access, etc.
|
In other words, timeshare. On a mid/mainframe yes, which is the
cpu cost reason again. But on a PC, is that even worth the trouble
to consider? Most IT dept. that I have seen wipe the disks and
reinstall a standard OS config to recycle a PC.
| Quote: | (c) Testing a new software release. As in the case of running
more than one OS, you can get by without having to buy and
manage another machine.
|
Similar to (a), this makes sense if there is a constraint on
getting e new machine. At $1000/box vs $1500/staff-day you don't
need too much futzing about with co-resident OS installs and
virtual device configuration to eat up all your savings.
| Quote: | (d) Isolating customers from each other. The typical OS can
do this for ordinary users, but not administrators. What
if you want to run Unix or Linux, but allow a teacher or
their assistant to have "root" relative to their students,
to kill off rogue processes, be able to view files, etc?
You could add a new security model; but you could just
grant them root to their virtualized machine.
|
That isolation should definitely be in an OS. If it isn't then I
would consider it an OS design failure and best addressed there.
Doing otherwise strikes me as fixing the symptom not the problem.
| Quote: | I'm sure there are other ideas for how this would be used.
|
OS driver and kernel debugging. But this is pretty niche too.
It seems to come down to cpu cost. In days of yor, on pricey
cpus VM made sense. But in a < $1000/PC universe
I don't see the justification outside of niche situations.
Buying a new box seems the path of least resistance and
most effective use of peoples time.
Eric |
|
| Back to top |
|
|
Eric P.
Guest
|
| Posted:
Thu Feb 10, 2005 12:22 am Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
Anne & Lynn Wheeler wrote:
| Quote: |
in any case there was an issue if the cp67 kernel that provided
virtual 370 machines was run on the bare hardware ... there might be
some of the area students stumble across the features (and they were
trying to fairly tightly control the secret of virtual memory for
370). in any case,
cp67-l kernel was run on bare hardware providing general computing
access
cp67-h kernel was run in a 360/67 virtual machine and it provided
370 virtual machines
cp67-i kernel was run in a 370 (virutal memory) virtual machine
cms was run in a 370 virtual machine
|
One of our more talented developers discovered how to coax VM/CMS
into doing shared memory sections: IIRC a privileged routine trundles
through the page table and resets the CopyOnWrite bit before spawning
sub VM's. Voila - shared comms memory between virtual machines.
Eric |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in