xen discuss - Feb 2006 - [xen-discuss] Virtualisation on sparc cpu ?

>From this url here,
http://news.zdnet.co.uk/hardware/0,39020351,39249156,00.htm

Are we going to get Virtualization on SPARC CPU ?
Do this mean we can run Solaris/sparce 2.[6|7|8|9|10] on a T1000 ?
Am I reading it right  this time ? 

tjyang
This message posted from opensolaris.org

well maybe not 2.6 and such but 10/11 :)
This message posted from opensolaris.org

> well maybe not 2.6 and such but 10/11 :)
If this is the case then this "logical domans" stuff is no better the
container.

tj
This message posted from opensolaris.org

Definitely no version of Solaris < 10 will run on the
UltraSPARC-T1 based systems.  The sun4v architecture
is introduced in Solaris 10.  "v" is the key letter :-)
 -- richard
This message posted from opensolaris.org

> Definitely no version of Solaris < 10 will run on
> the
> UltraSPARC-T1 based systems.  The sun4v architecture
> is introduced in Solaris 10.  "v" is the key letter
> :-)
>  -- richard
Ok, let me lower my standard a bit.

Will logical domain enable Solaris sparc <10 runs on older Sun hardware
(other than T1) then ?

The success of using VMware ESX to consolidate servers on Intel cpu make IT
center dream about VMware alike technology for sparc cpu.
 
tj
This message posted from opensolaris.org

* tj_yang at hotmail.com [20060207T000104]:
> Will logical domain enable Solaris sparc <10 runs on older Sun
> hardware (other than T1) then ?
The "logical domains" feature described in the article is currently
available only on systems using the UltraSPARC T1 processor
(i.e. those that are the sun4v architecture).

It''s unlikely that it will be supported on any other existing
UltraSPARC processors, though of course some newer ("as yet
unreleased") are expected to support the feature.

dme.
-- 
David Edmondson, Solaris Engineering, Sun Microsystems.

On Mon, 2006-02-06 at 15:49 -0800, TJ Yang wrote:
> > well maybe not 2.6 and such but 10/11 :)
> 
> If this is the case then this "logical domans" stuff is no better
the
container.

In what way, TJ ?   I don''t think of them as better, but rather
different and complementary solutions to broaden the scope of
virtualization.   There are some limitations of zones (one element
of containers) that might make it difficult to deploy an application.
The reduced privilege mode, the lack of loading drivers, inability to
walk through kernel memory, no DTrace (at the moment).  These
restrictions are what makes it more safe to house multiple applications
and help drive up operational and administrative efficiency (one
filesystem cache, one libc, patch once), but there will always be
cases where this is not the right solution.

I know nothing more about logical domains than what has been said
in a couple of press releases and reading the references that Richard
posted yesterday, but it would seem that this capability would allow
for things like separate kernels (at different versions), perhaps some
nice fault isolation from kernel failures (but this just assumed).

Another piece to the puzzle that shouldn''t be dismissed is the role
that
Branded Zones may play.   This notion of replacing the user space with
something different is terribly exciting.    By your comment, I''m
assuming that you have an older workload and you want to move it
to more modern hardware, but that new hardware has specific requirements
for the OS of today.  And its hard to go back and add chipset support
to older operating systems, yet one can note that there aren''t all
that many hardware dependencies in the user space (there are and they
can be devious as you expect certain behaviors out of system calls and
private interfaces - but if we can get Linux to work, Solaris would seem
much much easier to do).   Perhaps if we continue the development of
these capabilities we can prolong the useful lifespan of a user space
which would seem to be a tremendously good thing.   If you''re curious
about how this stuff works, take a peek at the BrandZ project at
http://opensolaris.org/os/community/brandz.


I''m trying to find an application that works under Solaris 10 but
doesn''t under nv31 (software express) so that I can test this
capability.   I think I know how to wedge in the Solaris 10 user
environment, but I don''t have the test case to know whether
it''s
really doing what it should.

Bob

David - ldoms are targeted for T1 processors, as opposed to USIV+, etc?
Also, are they available today for Niagara''s, or will it be for the
next
gen of T1? 

-----Original Message-----
From: xen-discuss-bounces at opensolaris.org
[mailto:xen-discuss-bounces at opensolaris.org] On Behalf Of
David.Edmondson at Sun.COM
Sent: Monday, February 06, 2006 4:35 PM
To: TJ Yang
Cc: xen-discuss at opensolaris.org
Subject: Re: [xen-discuss] Re: Virtualisation on sparc cpu ?

* tj_yang at hotmail.com [20060207T000104]:
> Will logical domain enable Solaris sparc <10 runs on older Sun 
> hardware (other than T1) then ?
The "logical domains" feature described in the article is currently
available only on systems using the UltraSPARC T1 processor (i.e. those
that are the sun4v architecture).

It''s unlikely that it will be supported on any other existing
UltraSPARC
processors, though of course some newer ("as yet
unreleased") are expected to support the feature.

dme.
--
David Edmondson, Solaris Engineering, Sun Microsystems.
_______________________________________________
xen-discuss mailing list
xen-discuss at opensolaris.org

> On Mon, 2006-02-06 at 15:49 -0800, TJ Yang wrote:
> > > well maybe not 2.6 and such but 10/11 :)
> > 
> > If this is the case then this "logical domans"
> stuff is no better than
> container.
> 
> In what way, TJ ?   I don''t think of them as better,
> but rather
> different and complementary solutions to broaden the
> scope of
> virtualization.   There are some limitations of zones
> (one element
> of containers) that might make it difficult to deploy
> an application.
> The reduced privilege mode, the lack of loading
> drivers, inability to
> walk through kernel memory, no DTrace (at the
> moment).  These
> restrictions are what makes it more safe to house
> multiple applications
> and help drive up operational and administrative
> efficiency (one
> filesystem cache, one libc, patch once), but there
> will always be
> cases where this is not the right solution.
> 
> I know nothing more about logical domains than what
> has been said
> in a couple of press releases and reading the
> references that Richard
> posted yesterday, but it would seem that this
> capability would allow
> for things like separate kernels (at different
> versions), perhaps some
> nice fault isolation from kernel failures (but this
> just assumed).
> 
> Another piece to the puzzle that shouldn''t be
> dismissed is the role that
> Branded Zones may play.   This notion of replacing
> the user space with
> something different is terribly exciting.    By your
> comment, I''m
> assuming that you have an older workload and you want
> to move it
> to more modern hardware, but that new hardware has
> specific requirements
> for the OS of today.  And its hard to go back and add
> chipset support
> to older operating systems, yet one can note that
Thanks for the detail reply, Bob.

My comment about solution of Logical domains and Zones is that I was hoping L.D.
for sparc  can allow us to create sessions to run all version of solaris sparc
OS.
This will help consolidation goal that most IT center are facing.  By retiring
old hardwares and migrate its services to central box.

I don''t know much about Zone/Containers except I played with it by
creating a few sessions on a sparc 10 after I attended the Zone presentation
from Sun.

I stop my learning efforts on Zones due to the  surrounding of solaris
2.[5.1|6|7|8|9].  Solaris 10 is still far away to be adopted(in my workplace).

It is hard I know, but if VMware can do it on Intel why Sun can''t do it
on Sparc ?
Also Sparc paltform has less hardware simulation work need to do than Intel
platform.

Without solution like VMware for Sparc platform, IMHO, whenever there is a
chance, people will  migrate their services running on Solaris and HP-UX to RH
linux.  Implement IT services on Intel/RH Linux will be a better choice becuase
of existence of VMware.

tj

> there aren''t all
> that many hardware dependencies in the user space
> (there are and they
> can be devious as you expect certain behaviors out of
> system calls and
> private interfaces - but if we can get Linux to work,
> Solaris would seem
> much much easier to do).   Perhaps if we continue the
> development of
> these capabilities we can prolong the useful lifespan
> of a user space
> which would seem to be a tremendously good thing.
>   If you''re curious
> about how this stuff works, take a peek at the BrandZ
> project at
> http://opensolaris.org/os/community/brandz.
> 
> 
> I''m trying to find an application that works under
> Solaris 10 but
> doesn''t under nv31 (software express) so that I can
> test this
> capability.   I think I know how to wedge in the
> Solaris 10 user
> environment, but I don''t have the test case to know
> whether it''s
> really doing what it should.
> 
> Bob
> 
> _______________________________________________
> xen-discuss mailing list
> xen-discuss at opensolaris.org
>
This message posted from opensolaris.org

On Tue, 7 Feb 2006, TJ Yang wrote:
> all version of solaris sparc OS. This will help consolidation goal 
> that most IT center are facing.  By retiring old hardwares and 
> migrate its services to central box.
> I stop my learning efforts on Zones due to the surrounding of 
> solaris 2.[5.1|6|7|8|9].  Solaris 10 is still far away to be 
> adopted(in my workplace).
I''m curious, if Solaris 10 is "still far away" for your
workplace
(presumably due to change-management processes or similar) then why 
would as yet undeveloped "generic sun4u logical domain" software make 
it through your process any quicker than Solaris 10?

If you have a qualification process for new Solaris releases with 
your applications, you can start that process off today and be using 
S10 zones long before you could ever use this generic-domain 
software.

Sun take backwards compatibility quite seriously, so there is a 
decent chance that your applications will run unchanced on S10 
(particularly if those applications were built for S8/9).

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
No spitting on the Bus!
Thank you, The Mgt.

On Tue, 7 Feb 2006, Paul Jakma wrote:
> due to change-management processes or similar) then why would as 
> yet undeveloped "generic sun4u logical domain" software make it 
> through your process any quicker than Solaris 10?
Oh btw, it''s not inconceivable that you could use Solaris Zones to 
run userspaces from older Solaris releases under a zone, with perhaps 
a bit of BrandZ hacking to make S10 kernel implement any 
removed/changed kernel interfaces (which typically should be few).

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
He who has but four and spends five has no need for a wallet.

* ian.c.campbell at eds.com [20060207T180300]:
> David - ldoms are targeted for T1 processors, as opposed to USIV+,
> etc?
The article seems pretty clear that the logical domains feature will
initially be available on the T1 based platforms.

I''m not sure how to interpret "targeted" in your question -
the T1
includes features that are necessary for the current implementation of
logical domains.  Other UltraSPARC processors don''t currently support
those features.

A revision of the USIV+ could add the required features - I genuinely
have no information either way about whether that will happen.
> Also, are they available today for Niagara''s, or will it be for
the
> next gen of T1?
My understanding is that the current generation T1 chips will be
supported.

Some of these border on what I''d call "product" questions -
it might
be better to get an answer from your account manager (EDS must have
quite a few Sun account managers :-)).

dme.
-- 
David Edmondson, Solaris Engineering, Sun Microsystems.

On 2/7/06, Paul Jakma <paul at clubi.ie> wrote:
> On Tue, 7 Feb 2006, Paul Jakma wrote:
>
> > due to change-management processes or similar) then why would as
> > yet undeveloped "generic sun4u logical domain" software make
it
> > through your process any quicker than Solaris 10?
>
> Oh btw, it''s not inconceivable that you could use Solaris Zones to
> run userspaces from older Solaris releases under a zone, with perhaps
> a bit of BrandZ hacking to make S10 kernel implement any
> removed/changed kernel interfaces (which typically should be few).
>
Branded zones to serve as targets for P2V (physical to virtual, in
VMware speak) would be wonderful.  Flar up a Solaris 8 box, play it
into a zone, and know that I have support from Sun.  If I run into ISV
problems, I can flar it up and take it to a greatly reduced quantity
of older servers to work through support problems with the ISV. 
Presumably, this would allow consolidation of older releases to
hardware that is incompatible with those releases (due to kernel, not
user space).

Is it a clean way to run things?  Nope.  However, the things that
companies find worthwhile to support (improve, maintain application
code, integrations, etc.) for a long while will get maintained in a
much cleaner manner.  Those things that have lost their maintainers
and have a few somewhat important functions that need to still be
performed (use almost no CPU, almost no RAM) could benefit greatly. 
Then Sun could do commercials showing how they consolidated racks of
220''s, 420''s, 450''s, etc. into a single T2000.

Mike

> On Tue, 7 Feb 2006, TJ Yang wrote:
> 
> > all version of solaris sparc OS. This will help consolidation goal 
> > that most IT center are facing.  By retiring old hardwares and 
> > migrate its services to central box.
> 
> > I stop my learning efforts on Zones due to the surrounding of 
> > solaris 2.[5.1|6|7|8|9].  Solaris 10 is still far away to be 
> > adopted(in my workplace).
> 
> I''m curious, if Solaris 10 is "still far away" for your
workplace
> (presumably due to change-management processes or
> similar) then why  would as yet undeveloped "generic sun4u logical
> domain" software make it through your process any quicker than Solaris
10?
Similarly, why is the sudden jump to VMWare acceptable (which is
an OS in itself) whereas a jump to a new, full function OS isn''t?
Is there some myth about VMWare supported every possible thing
without bugs that I''m unaware of?

One major drawback of virtualization is that it adds to the software
stack which increases complexity and opportunity for version hell.
 -- richard
This message posted from opensolaris.org

On 2/7/06, Richard Elling <Richard.Elling at sun.com>
wrote:
> Similarly, why is the sudden jump to VMWare acceptable (which is
> an OS in itself) whereas a jump to a new, full function OS isn''t?
> Is there some myth about VMWare supported every possible thing
> without bugs that I''m unaware of?
>From what I have seen, the transition of a 4 year old x86 box to a
VMware guest is acceptable (and often preferable to an upgrade) for
the following reasons:

- Too many old machines taking up power, space, cooling, switch ports,
etc. and a "quick fix" is desired.  (Fast, Cheap, Good - pick two?)
- Intellectual capital and/or installation media is missing (career
mobility, outsourcing, reorgs, etc.).  As such, the only way to get on
an updated OS is through upgrades which are not universally trusted.
- Old application may not be certified and/or supported on the newer OS.
- Using P2V, the OS image can be picked up and moved into a VM with
minimal effort.  Device drivers change, but not much else.  I believe
that tools exist for V2P (backout plan) just in case things don''t go
as well as planned.
- VMware has done a great job of garnering ISV and IHV support for the
notion that using VM''s are safe (secure, reliable, etc.) and cost
effective.
- So far I have only heard of Microsoft suggesting that some of their
server products (domain controllers) are not supported in VM''s.  I
suspect that in the next round of US/EU vs. MS this marketing tactic
will be on the laundry list of anti-competitive practices.
- The old notion that "fewer machines (distinct hardware boxes) are
easier to manage".  There is some truth to this, however, management
rarely looks at the complexity of the machines (25k vs. 18 V490''s) or
number of OS''s managed.
> One major drawback of virtualization is that it adds to the software
> stack which increases complexity and opportunity for version hell.
Yup.  A key to the success of virtualization is that it needs to pay
back in some way that makes up for the complexity.  For example,
reducing 42U down to 2U - 4U is a good payback.  Making it so that a
workload is "contained" and the container in which it lives can be
quickly and easily migrated to another set of physical hardware is a
good payback.  VMware does this with Vmotion with no outage.  With
Solaris 10 and some scripting, I do this in less than a minute of
application downtime.

Think back a few years.  The virtualization of memory has proven very
successful because of the robustness and flexibility of memory
management that it has offered.

Mike

> On 2/7/06, Richard Elling <Richard.Elling at sun.com> wrote:
> > Similarly, why is the sudden jump to VMWare acceptable (which is
> > an OS in itself) whereas a jump to a new, full function OS
isn''t?
> > Is there some myth about VMWare supported every possible thing
> > without bugs that I''m unaware of?
> 
> >From what I have seen, the transition of a 4 year old x86 box to a
> VMware guest is acceptable (and often preferable to an upgrade) for
> the following reasons:
I don''t disagree, but we''ve strayed.  My point was that if
someone
can''t upgrade from Solaris 2.6 to Solaris 9 or 10 (ten years later)
because of change control restrictions, then why does VMWare
get a free ride?  It should be held to the same standard.

More thoughts and responses to this interesting post below...
> - Too many old machines taking up power, space, cooling, switch ports,
> etc. and a "quick fix" is desired.  (Fast, Cheap, Good - pick
two?)
> - Intellectual capital and/or installation media is missing (career
> mobility, outsourcing, reorgs, etc.).  As such, the only way to get on
> an updated OS is through upgrades which are not universally trusted.
And adding another layer to the stack is trusted?  hmmmm....
A quick glance at
http://www.vmware.com/support/guestnotes/doc/guestos_solaris10.html
shows a rather disturbing number of revisions which would need to
be qualified prior to rollout to production.  I think Andy Tucker''s
blog
and comments confirm my beliefs.
http://atucker.typepad.com/blog/2005/11/more_on_vmware_.html

I''m not bashing VMWare, it is very cool, but it is just another layer
in the
stack.  Xen, BrandZ, and the SPARC hypervisor is in the same boat.
> - Old application may not be certified and/or supported on the newer OS.
> - Using P2V, the OS image can be picked up and moved into a VM with
> minimal effort.  Device drivers change, but not much else.  I believe
> that tools exist for V2P (backout plan) just in case things don''t
go
> as well as planned.
> - VMware has done a great job of garnering ISV and IHV support for the
> notion that using VM''s are safe (secure, reliable, etc.) and cost
effective.
Yes, good marketing works  :-)
> - So far I have only heard of Microsoft suggesting that some of their
> server products (domain controllers) are not supported in VM''s.  I
> suspect that in the next round of US/EU vs. MS this marketing tactic
> will be on the laundry list of anti-competitive practices.
I can''t agree with you here.  I have extensive experience
with ISVs like Oracle, Semantec, CAD/CAE vendors, and
others who have an absolutely anal retentive policy about
the supported stacks.  It is far more likely that they have never
tested those combinations, but aren''t savvy enough to say so.
In theory, they are probably relatively safe, given the wide
variance of x86 hardware they have to take a liberal approach
to supported configurations already.  If the machine only costs
$1k, then it is easier for customer service to say "buy another
machine."
> - The old notion that "fewer machines (distinct hardware boxes) are
> easier to manage".  There is some truth to this, however, management
> rarely looks at the complexity of the machines (25k vs. 18 V490''s)
or
> number of OS''s managed.
Yes, the number of OSes dominates the TCO equation.
> > One major drawback of virtualization is that it adds to the software
> > stack which increases complexity and opportunity for version hell.
> 
> Yup.  A key to the success of virtualization is that it needs to pay
> back in some way that makes up for the complexity.  For example,
> reducing 42U down to 2U - 4U is a good payback.  Making it so that a
> workload is "contained" and the container in which it lives can
be
> quickly and easily migrated to another set of physical hardware is a
> good payback.  VMware does this with Vmotion with no outage.  With
> Solaris 10 and some scripting, I do this in less than a minute of
> application downtime.
Yes.  But the reason this tends to work today is because systems
tend to be (massively) underutilized.  Those systems which have
critical requirements tend to not be good candidates for such
consolidation.
> Think back a few years.  The virtualization of memory has proven very
> successful because of the robustness and flexibility of memory
> management that it has offered.
[getting further off topic...]  I don''t follow you here.  Virtual
memory has
significantly less reliability than a flat memory heirarchy.  But it also
has significantly less cost.  I think it was the cost that drove virtual
memory migration.  Fortunately, this is relatively easy to administer
even with the flexibility, so in general, it is a bonafide good thing.
I''m not convinced virtual machines will be good things in general, 
including JVMs.  We''ll see...
 -- richard
This message posted from opensolaris.org

On Tue, 2006-02-07 at 18:05, TJ Yang wrote:
> Without solution like VMware for Sparc platform, IMHO, whenever there is a
chance, people will  migrate their services running on Solaris and HP-UX to RH
linux.  Implement IT services on Intel/RH Linux will be a better choice becuase
of existence of VMware.
Please explain why it is acceptable risk to migrate to a completely
different operating system on completely different hardware (ie Solaris
on SPARC to Linux on x86) yet it isn''t acceptable to upgrade to a newer
release of Solaris ?  Particularly since the Solaris binary product has
a compatibility guarantee for binaries built on older releases using
only public (and not EOF''d) interfaces.

-- 
Darren J Moffat

On Tue 02/07/06 at 18:38 PM, paul at clubi.ie wrote:
> On Tue, 7 Feb 2006, Paul Jakma wrote:
> 
> >due to change-management processes or similar) then why would as 
> >yet undeveloped "generic sun4u logical domain" software make
it
> >through your process any quicker than Solaris 10?
> 
> Oh btw, it''s not inconceivable that you could use Solaris Zones to
> run userspaces from older Solaris releases under a zone, with perhaps 
> a bit of BrandZ hacking to make S10 kernel implement any 
> removed/changed kernel interfaces (which typically should be few).
It''s actually pretty close to inconceivable.

The public Solaris ABIs and APIs are stable between releases, so old
well-behaved applications are guaranteed to continue to work.  The
interface between libc and the kernel is private and completely unstable.
It can be changed on a whim between Solaris builds.  If you try to install
a Nevada build 31 userspace in a zone on a Nevada build 32 system, it could
fall over.  If you install a Solaris 8 userspace in a zone on a Nevada
system, I guarantee that it will fail spectacularly.

Making an S8 environment work on S10 is not just a matter of inserting a
thin shim layer between the two.  Just thinking about the complications
involved with the thread model changes between the two releases, I suspect
this would be a harder project than getting the Linux userspace working on
top of Solaris.

Nils

> On Tue, 2006-02-07 at 18:05, TJ Yang wrote:
> 
> > Without solution like VMware for Sparc platform,
> IMHO, whenever there is a chance, people will
> migrate their services running on Solaris and HP-UX
> X to RH linux.  Implement IT services on Intel/RH
> Linux will be a better choice becuase of existence of
> VMware.
> 
> Please explain why it is acceptable risk to migrate
> to a completely
> different operating system on completely different
> hardware (ie Solaris
> on SPARC to Linux on x86) yet it isn''t acceptable to
> upgrade to a newer
> release of Solaris ?  Particularly since the Solaris
> binary product has
> a compatibility guarantee for binaries built on older
> releases using
> only public (and not EOF''d) interfaces.
Darren, 

You are right, the risk (or the effort) is much more higher to migrate existing
service onto a new OS. Good catch of logical flaw in my above statement. I stand
corrected.

I should have said "implement the (new) service" instead of
"mirgrate their (existing) service".

My observation/feeling is that RHLinux+VMware solution is much perferred choice
for implementing a service(web,mail,application) or for developement activties.


tj







  


> -- 
> Darren J Moffat 
> 
> _______________________________________________
> xen-discuss mailing list
> xen-discuss at opensolaris.org
>
This message posted from opensolaris.org

> * ian.c.campbell at eds.com [20060207T180300]:
> > David - ldoms are targeted for T1 processors, as
> opposed to USIV+,
> > etc?
> 
> The article seems pretty clear that the logical
> domains feature will
> initially be available on the T1 based platforms.
To Sun,  yes this is right approach, pushing customer to buy new T1 just to get
logical domain.

To me(sun customer), this is wrong. the order/priority of supporting different
Sparc CPU should be older CPU first then T1 sparc precessors.

tj
> I''m not sure how to interpret "targeted" in your
> question - the T1
> includes features that are necessary for the current
> implementation of
> logical domains.  Other UltraSPARC processors don''t
> currently support
> those features.
> 
> A revision of the USIV+ could add the required
> features - I genuinely
> have no information either way about whether that
> will happen.
> 
> > Also, are they available today for Niagara''s, or
> will it be for the
> > next gen of T1?
> 
> My understanding is that the current generation T1
> chips will be
> supported.
> 
> Some of these border on what I''d call "product"
> questions - it might
> be better to get an answer from your account manager
> (EDS must have
> quite a few Sun account managers :-)).
> 
> dme.
> -- 
> David Edmondson, Solaris Engineering, Sun
> Microsystems.
> _______________________________________________
> xen-discuss mailing list
> xen-discuss at opensolaris.org
>
This message posted from opensolaris.org

* tj_yang at hotmail.com [20060211T110335]:
> > The article seems pretty clear that the logical
> > domains feature will
> > initially be available on the T1 based platforms.
> 
> To Sun, yes this is right approach, pushing customer to buy new T1
> just to get logical domain.
> 
> To me(sun customer), this is wrong. the order/priority of supporting
> different Sparc CPU should be older CPU first then T1 sparc
> precessors.
As currently designed and implemented, logical domains requires
features that are only available in the UltraSPARC T1 processors.

dme.
-- 
David Edmondson, Solaris Engineering, Sun Microsystems.

Putting the hooks in hardware is the way to go. Look at Intel/AMD with their
upcoming extentions. Yes virualization can work without the hooks into the
CPU/IO but wait until you see AMD''s virtualization and then compare it
to
anything from VMware before. It will be a big performance boost plus it
makes other items possible like XEN running things without kernel mods.

I work at a site with hundreds of older Sparcs and yes I would love to get
total system VMs out of them but realisticly we''ll use them with zones
where
that works and use the new T1s for true system VMs.

On 2/12/06, David.Edmondson at sun.com <David.Edmondson at sun.com>
wrote:
>
> * tj_yang at hotmail.com [20060211T110335]:
> > > The article seems pretty clear that the logical
> > > domains feature will
> > > initially be available on the T1 based platforms.
> >
> > To Sun, yes this is right approach, pushing customer to buy new T1
> > just to get logical domain.
> >
> > To me(sun customer), this is wrong. the order/priority of supporting
> > different Sparc CPU should be older CPU first then T1 sparc
> > precessors.
>
> As currently designed and implemented, logical domains requires
> features that are only available in the UltraSPARC T1 processors.
>
> dme.
> --
> David Edmondson, Solaris Engineering, Sun Microsystems.
> _______________________________________________
> xen-discuss mailing list
> xen-discuss at opensolaris.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/xen-discuss/attachments/20060212/806ab30f/attachment.html>