Re: [zones-discuss] zone UUID in older releases

[James Carlson]

Brian Warkentine writes:
> I see that printing of the zone uuid has been added to zoneadm recently 
> (around the end of june this year, according to the online source).  Is 
> there any binary that will print uuid for older releases? 

No.

This was added for the Zulu (Zones Live Upgrade) project, so there
will be a Solaris 10 update in the near future that has this.  (Is
that what you're asking about?  I'm not sure what "older releases"
refers to here.)

> I've looked around, it's in the zone_t structure, but that looks like 
> its not accessible in userland.

UUID is in the zoneent structure, which is entirely in user space.
The kernel's zone_t structure (in ) doesn't have the UUID,
and the kernel neither knows nor cares about Zone UUIDs.

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/head/libzonecfg.h#zoneent

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[James Carlson]

Erik Nordmark writes:
> Jeff Victor wrote:
> > Here's one reason: consistency.  All users in the GZ can see some 
> > inforamtion about non-global zones (e.g. "ps").  Privileged GZ users can 
> > see all info about non-global zones, and need to do so in order to 
> > manage them.
> 
> But the exclusive-IP behavior is quite different from the shared-IP 
> behavior; it offers complete IP isolation between different zones/IP 
> instances.

I don't think that argument works on two counts.  First, exclusive-IP
behavior does not offer complete IP isolation, because you can't (for
instance) install your own copy of Firewall-1 or Cisco VPN into a
non-global exclusive-IP zone.  Some things do still require global
zone administration.  Second, "ps" shows processes that the user in
the global zone cannot 'administer' by way of kill(2), so they are at
least as isolated as IP instances, but they're still of interest to
global zone administrators who want a global view of the system.

All that said, I think making ifconfig list the interfaces present in
exclusive-IP zones, given the design of ifconfig, would be
prohibitively difficult.  It'd have no access to the DLPI nodes, which
is where it gets some of its information, and the ioctls it uses for
tunnels and the like won't work well if the zones have independent
control of the interfaces.  (It'd work "for now," but I think it'd end
up representing more confusion with Clearview, as there'd be no easy
way to coordinate interface names across multiple zones, so
ifta_lifr_name would be ambiguous.)

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] zone UUID in older releases

[Jeff Victor]

Brian Warkentine wrote:
I see that printing of the zone uuid has been added to zoneadm recently 
(around the end of june this year, according to the online source).  Is 
there any binary that will print uuid for older releases? 


Why?  That ID is only intended for internal consumption.

Also, it did not exist in S10 3/05, so the window of time that it existed in 
"older releases" is very small.




I've looked around, it's in the zone_t structure, but that looks like 
its not accessible in userland.





--
--
Jeff VICTOR  Sun Microsystemsjeff.victor @ sun.com
OS AmbassadorSr. Technical Specialist
Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq
--
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] zone UUID in older releases

[James Carlson]

Jeff Victor writes:
> Brian Warkentine wrote:
> > I see that printing of the zone uuid has been added to zoneadm recently 
> > (around the end of june this year, according to the online source).  Is 
> > there any binary that will print uuid for older releases? 
> 
> Why?  That ID is only intended for internal consumption.

Actually, we're now exposing it via "zoneadm list -p" intentionally,
because there are customers who apparently want to use it as some sort
of "asset tag."

I'm not sure _why_ it's useful this way, but I'm reliably informed
that there are people who care, and it was easy enough to provide.
;-}

Anyway, the semantics are simple and don't involve kernel state: when
the zone is installed ("zoneadm install"), the zone gets a new UUID.
The UUID remains stable over renames, moves, and LU BE copies.  It is
destroyed if the zone is uninstalled.

This way, we can tell when a zone in two BEs is the same zone but just
under a different name (thus still needing synchronization), and when
someone destroys and re-creates a zone under the same name (thus not
needing synchronization).

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Zones and multiple IP address

[Roshan Perera]

Stefan,
Thanks for your reply. Yes, I found the way infact I wasted a day trying to get 
it working because zonecfg add net only support one entry at a time. 
Each time you have to end add net and then do a add net again for the 2nd IP. 
Which is what caused me to seek help.

Thanks again.

Roshan



- Original Message -
From: Steffen Weiberle <[EMAIL PROTECTED]>
Date: Tuesday, November 7, 2006 4:45 pm
Subject: Re: [zones-discuss] Zones and multiple IP address
To: Roshan Perera <[EMAIL PROTECTED]>
Cc: zones-discuss@opensolaris.org

> Roshan Perera wrote On 11/07/06 05:35,:
> > Hi all,
> > 
> > Can someone let me know whether a non global zone can have 
> multiple IP addresses ? 
> 
> Yes. Yes.
> 
> If so can it be serviced by
> > 2 NIC's with IPMP running in the global zone. 
> 
> Yes. I *must* be managed via IPMP from the global zone. When you 
> configure the non-global zone, you 
> only need to indicate one interface of the IPMP group.
> 
> Steffen
> 
> eg: global IP's are
> > 
> > ce0  x.x.x.1
> > ce0:5   x.x.y.10
> > 
> > Zone1 to have x.x.x.10 using ce0 and also service x.x.y.20 using 
> ce0:5> 
> > I have asked the same question previously (attached below) 
> without any luck with VLAN tagging but this time I'm trying to 
> simplify the problem. Then I can get the VLAN tagging working.
> > 
> > I am at customer and customer keen to have this done. 
> > 
> > Rgds
> > 
> > Roshan
> > 
> > 
> > 
> > 
> > - Original Message -
> > From: Roshan Perera <[EMAIL PROTECTED]>
> > Date: Monday, November 6, 2006 11:49 am
> > Subject: Re: [zones-discuss] Zones and VLAN tagging.
> > To: zones-discuss@opensolaris.org
> > 
> > 
> >>I have VLAN tagging working OK THanks to the James Carlson, Mike 
> >>Gerdts, Steffen Weiberle in particular.
> >>Now I have a further question and similar help will be muchly 
> >>appreciated.
> >>I have IPMP in 2 interfaces.eg:
> >>Global Zone IP address  10.10.10.5 (IPMP real)
> >>   ce0  10.10.10.6 (IPMP test)
> >>   ce1  10.10.10.7 (IPMP test)
> >>
> >>zone1 IP 10.10.10.10
> >>zone2 IP 10.10.10.20
> >>
> >>Currently I have ce61 and ce610001 configured for the above 
> >>and working OK with zones IP's fine.
> >>
> >>Now I like the Same IPMP interfaces ce0 and ce1 as above to 
> >>service another IP for global and zones. eg: 
> >>
> >>10.10.20.5 for the global zone
> >>10.10.20.10 for the zone1
> >>10.10.20.20 for the zone2
> >>
> >>I assume this is possible. I tried couple of shots at it. But 
> >>fails. Can someone kindly help./.
> >>
> >>Roshan
> >>
> >>
> >>
> >>
> >>- Original Message -
> >>From: Roshan Perera <[EMAIL PROTECTED]>
> >>Date: Monday, October 23, 2006 5:18 pm
> >>Subject: Re: [zones-discuss] Zones and VLAN tagging.
> >>To: James Carlson <[EMAIL PROTECTED]>
> >>Cc: zones-discuss@opensolaris.org
> >>
> >>
> >>>Guys,
> >>>
> >>>Yes, the problem seems to be CR 6367840. As long as the IPMP 
> >>>interfaces are in FAILED mode non global zones will not boot 
> >>
> >>after 
> >>
> >>>configuration.
> >>>Have fixed the network and all seems to be fine.
> >>>
> >>>Thanks
> >>>
> >>>Roshan
> >>>
> >>>- Original Message -
> >>>From: James Carlson <[EMAIL PROTECTED]>
> >>>Date: Monday, October 23, 2006 2:41 pm
> >>>Subject: Re: [zones-discuss] Zones and VLAN tagging.
> >>>To: Mike Gerdts <[EMAIL PROTECTED]>
> >>>Cc: Roshan Perera <[EMAIL PROTECTED]>, zones-
> >>>[EMAIL PROTECTED]
> >>>
> Mike Gerdts writes:
> 
> >On 10/23/06, Roshan Perera <[EMAIL PROTECTED]> wrote:
> >
> >>zonecfg:sz44bsdvapdqc02:net> set address=10.165.20.35/23
> >
> >That should be:
> >
> >set address=10.165.20.35
> >
> >You will then need an entry in the global zone's 
> >>
> >>/etc/netmasks to
> >>
> >ensure that the netmask is set properly as the zone is booted.
> 
> There's nothing wrong with CIDR notation here.  In fact, I'd 
> >>>
> >>>recommend> that users prefer CIDR and shy away from the ancient 
> >>>and feeble
> >>>
> /etc/netmasks interface.
> 
> See the zonecfg(1M) man page for details.
> 
> That's not the problem the user is seeing.  The problem the 
> >>
> >>user is
> >>
> experienced appears to be CR 6367840 -- fixed in Nevada, but 
> >>
> >>not 
> >>
> >>>S10.> 
> >>>
> -- 
> James Carlson, KISS Network
> <[EMAIL PROTECTED]>Sun Microsystems / 1 Network Drive
> >>
> >> 
> >>
> >>> 
> >>>
> 71.232W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> >>
> >>781 
> >>
> 442 1677
> 
> >>>
> >>>___
> >>>zones-discuss mailing list
> >>>zones-discuss@opensolaris.org
> >>>
> >>
> >>___
> >>zones-discuss mailing list
> >>zones-discuss@opensolaris.org
> >>
> > 
> > ___
> > zones-discuss mailing list
> > zones

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow

[David . Comay]

If we want any form of internal consistency, wouldn't we also need to change 
were we assign datalink names from zonecfg to dladm?


Thus no more 'net' resource in zonecfg for exclusive-IP zones, but instead 
some

dladm set-zone zoneA bge1

Only having dladm show it, and not be able to affect it, seems quite 
inconsistent.


As Dan pointed out, there are already other commands such as
ifconfig(1M) and mount(1M) which manipulate or observe resources
assigned to a zones so using dladm(1M) wouldn't be that inconsistent.

I think the objection is around adding a resource-specific option to
"zoneadm list".  Rather than waiting for the "info" command, what about
introducing a "-o " option instead where "datalinks" or
something like that can be used to indicate you wish to select the data
links of each zone as the information to be printed?

dsc
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[Erik Nordmark]

James Carlson wrote:


I don't think that argument works on two counts.  First, exclusive-IP
behavior does not offer complete IP isolation, because you can't (for
instance) install your own copy of Firewall-1 or Cisco VPN into a
non-global exclusive-IP zone. 


Agreed you can't do that. But how does that make IP packets leak between 
different exclusive-IP zones?

Perhaps we have a different definition of what "IP isolation" means?
To me the critical property is that there is no IP packet leakage.


Some things do still require global
zone administration.  Second, "ps" shows processes that the user in
the global zone cannot 'administer' by way of kill(2), so they are at
least as isolated as IP instances, but they're still of interest to
global zone administrators who want a global view of the system.


I tried the kill and AFAICT root in the global zone can kill a process 
in a non-global zone:

bilen# ptree 103436
100996 gnome-terminal
  100999 csh
101003 -csh
  103331 zlogin 49bge
103332 -sh
  103338 csh
103436 cat
bilen# kill 103436
(and the cat process in the 49bge zone died).


All that said, I think making ifconfig list the interfaces present in
exclusive-IP zones, given the design of ifconfig, would be
prohibitively difficult.  It'd have no access to the DLPI nodes, which
is where it gets some of its information, and the ioctls it uses for
tunnels and the like won't work well if the zones have independent
control of the interfaces.  (It'd work "for now," but I think it'd end
up representing more confusion with Clearview, as there'd be no easy
way to coordinate interface names across multiple zones, so
ifta_lifr_name would be ambiguous.)


I agree it would be a pain to implement. zone_enter() would be one way.

But the key thing to me is the consistency between where things can be 
observed and where they can be modified.


   Erik


___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[James Carlson]

Erik Nordmark writes:
> James Carlson wrote:
> 
> > I don't think that argument works on two counts.  First, exclusive-IP
> > behavior does not offer complete IP isolation, because you can't (for
> > instance) install your own copy of Firewall-1 or Cisco VPN into a
> > non-global exclusive-IP zone. 
> 
> Agreed you can't do that. But how does that make IP packets leak between 
> different exclusive-IP zones?

It doesn't make the packets leak.  It makes the administrative
activities leak.

> Perhaps we have a different definition of what "IP isolation" means?
> To me the critical property is that there is no IP packet leakage.

I don't think it's the only property.

> > Some things do still require global
> > zone administration.  Second, "ps" shows processes that the user in
> > the global zone cannot 'administer' by way of kill(2), so they are at
> > least as isolated as IP instances, but they're still of interest to
> > global zone administrators who want a global view of the system.
> 
> I tried the kill and AFAICT root in the global zone can kill a process 
> in a non-global zone:

OK.  I must be misremembering this.  I thought the restriction was
more complex than that.

> > All that said, I think making ifconfig list the interfaces present in
> > exclusive-IP zones, given the design of ifconfig, would be
> > prohibitively difficult.  It'd have no access to the DLPI nodes, which
> > is where it gets some of its information, and the ioctls it uses for
> > tunnels and the like won't work well if the zones have independent
> > control of the interfaces.  (It'd work "for now," but I think it'd end
> > up representing more confusion with Clearview, as there'd be no easy
> > way to coordinate interface names across multiple zones, so
> > ifta_lifr_name would be ambiguous.)
> 
> I agree it would be a pain to implement. zone_enter() would be one way.
> 
> But the key thing to me is the consistency between where things can be 
> observed and where they can be modified.

We already have RFEs filed against other utilities because they don't
show non-global zone activity (see, for example, CR 6369726).  I think
the lines here are pretty blurry.

In some usage models, the global zone administrator "owns"
everything.  Even if he can't directly control things from the global
zone (and must log into the non-global zone to turn services on and
off), he wants to see a view of the system that includes everything.

In other usage models, the global zone administrator just provides
"infrastructure" and has no business looking at non-global zones.  And
we've had requests to lock down the global zone so it can't look where
it shouldn't.

Given that there are some networking things that must be administered
in the global zone alone even when exclusive stack instances are in
use, it doesn't seem unreasonable to me to say that the administrator
of the global zone should be able to list related information without
entering the non-global zone.

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow

[Erik Nordmark]

[EMAIL PROTECTED] wrote:
If we want any form of internal consistency, wouldn't we also need to 
change were we assign datalink names from zonecfg to dladm?


Thus no more 'net' resource in zonecfg for exclusive-IP zones, but 
instead some

dladm set-zone zoneA bge1

Only having dladm show it, and not be able to affect it, seems quite 
inconsistent.


As Dan pointed out, there are already other commands such as
ifconfig(1M) and mount(1M) which manipulate or observe resources
assigned to a zones so using dladm(1M) wouldn't be that inconsistent.


Yes, but those provide for manipulation (aka change) and observability 
in the same place.


> Rather than waiting for the "info" command, what about
> introducing a "-o " option instead where "datalinks" or
> something like that can be used to indicate you wish to select the data
> links of each zone as the information to be printed?

Wouldn't this set a precedent that other things be available as -o?
E.g. -o uuid, -o brand, ...

Only introducing '-o datalinks' and never introducing any other -o 
specifiers bit instead moveingto an info subcommand for subsequent ones 
seems odd.


If you commit to adding other -o specifiers in short order, then I can 
see the benefit of introducing '-o datalinks' as part of IP Instances. 
If not, then this seems like a dead end to me.


   Erik

___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[Erik Nordmark]

James Carlson wrote:

Erik Nordmark writes:


But the key thing to me is the consistency between where things can be 
observed and where they can be modified.


We already have RFEs filed against other utilities because they don't
show non-global zone activity (see, for example, CR 6369726).  I think
the lines here are pretty blurry.

In some usage models, the global zone administrator "owns"
everything.  Even if he can't directly control things from the global
zone (and must log into the non-global zone to turn services on and
off), he wants to see a view of the system that includes everything.


Do you have an example of that?


In other usage models, the global zone administrator just provides
"infrastructure" and has no business looking at non-global zones.  And
we've had requests to lock down the global zone so it can't look where
it shouldn't.


I know the about is quite blurry - I sure wish zone administration was 
more self-consistent.



Given that there are some networking things that must be administered
in the global zone alone even when exclusive stack instances are in
use, it doesn't seem unreasonable to me to say that the administrator
of the global zone should be able to list related information without
entering the non-global zone.


ifconfig displays network interface names used by IP and IP addresses 
and related information.


zoneadm list -l displays the datalink names assigned to an exclusive-IP 
zone.


Are you saying that the datalink names are insufficient for the 
administration the global zone would need to do for the exlusive-IP zone?


There are things external to the system (such a firewalls) that might 
need to be configured with IP addresses, and I can see the same thing 
being true for the global zone (e.g. the global zone might run a 
firewall in front of the non-global zone down the road).
But I don't see that particular type of configuration as an argument for 
being able to do ifconfig -a in the global zone and see the non-global 
information, any more than there being a requirement for a router 
outside the system being able to do ifconfig -a and see the IP 
configuration of other systems on the network.


Thus I am trying to understand what the architectural or design 
principle is that makes you conclude that showing IP address 
configuration for exclusive-IP zones in ifconfig in the global zone.


Erik


___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[James Carlson]

Erik Nordmark writes:
> James Carlson wrote:
> > Erik Nordmark writes:
> 
> >> But the key thing to me is the consistency between where things can be 
> >> observed and where they can be modified.
> > 
> > We already have RFEs filed against other utilities because they don't
> > show non-global zone activity (see, for example, CR 6369726).  I think
> > the lines here are pretty blurry.
> > 
> > In some usage models, the global zone administrator "owns"
> > everything.  Even if he can't directly control things from the global
> > zone (and must log into the non-global zone to turn services on and
> > off), he wants to see a view of the system that includes everything.
> 
> Do you have an example of that?

I'm not sure I understand the question.  Is CR 6369726 a suitable
example?  If not, then what are you asking?

> > Given that there are some networking things that must be administered
> > in the global zone alone even when exclusive stack instances are in
> > use, it doesn't seem unreasonable to me to say that the administrator
> > of the global zone should be able to list related information without
> > entering the non-global zone.
> 
> ifconfig displays network interface names used by IP and IP addresses 
> and related information.
> 
> zoneadm list -l displays the datalink names assigned to an exclusive-IP 
> zone.
> 
> Are you saying that the datalink names are insufficient for the 
> administration the global zone would need to do for the exlusive-IP zone?

Yes, if the administrator of the global zone needs to know what
networks are involved in order to make a change.

For example, if the administrator of the global zone has Firewall-1
installed, he's going to need to configure IP details in the global
zone.  I don't see how he can do that if he doesn't have access to
them.

> There are things external to the system (such a firewalls) that might 
> need to be configured with IP addresses, and I can see the same thing 
> being true for the global zone (e.g. the global zone might run a 
> firewall in front of the non-global zone down the road).

Right.

> But I don't see that particular type of configuration as an argument for 
> being able to do ifconfig -a in the global zone and see the non-global 
> information, any more than there being a requirement for a router 
> outside the system being able to do ifconfig -a and see the IP 
> configuration of other systems on the network.

It depends on the administrator's mental model for the system.

Seeing IP addresses for other systems on the same network would not be
a rational thing to expect out of ifconfig.  Seeing IP addresses
configured inside the very same box on the very same running kernel,
though, may well be a rational expectation.

> Thus I am trying to understand what the architectural or design 
> principle is that makes you conclude that showing IP address 
> configuration for exclusive-IP zones in ifconfig in the global zone.

The design principle is that we have different tools for different
tasks, and those tools are expected to give you a coherent view of the
system.  I do expect to use the resource control commands to control
resources that I'm going to delegate to zones.  I do expect to be able
to view mount points and devices in use on the local system using
tools designed for those purposes, regardless of what zone is
involved.

I don't expect to use one tool to list datalinks and IP interfaces
when they're in my local zone (dladm, ifconfig) and a completely
different tool when they're in the same system but in some other
zone.  That's not the model we had been using, which is why ifconfig
currently does show interfaces in non-global zones, even though you
can't "use" those interfaces in the global zone.

The exception is where zonecfg sets up boundary conditions for a given
zone, and thus must take on tasks from other subsystems, but even in
those cases, I expect the 'native' (non-zones) tools to work as well
with those resources as with ones in the global zone.

In fact, I don't see what it has to do with zoneadm.  The question is
whether there's a single global view of the resources on the system.
If the answer is "no," then I suspect we'll end up needing to find a
way to provide that view, because that hasn't been a broadly accepted
answer in the past.

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow

[David . Comay]

As Dan pointed out, there are already other commands such as
ifconfig(1M) and mount(1M) which manipulate or observe resources
assigned to a zones so using dladm(1M) wouldn't be that inconsistent.


Yes, but those provide for manipulation (aka change) and observability in the 
same place.


However, dladm(1M) is still the place (from the global zone) where such
datalinks are instantiated, right?  For example, isn't that the method
in which VNICs are created is through dladm?  Or aggregated links?


Rather than waiting for the "info" command, what about
introducing a "-o " option instead where "datalinks" or
something like that can be used to indicate you wish to select the data
links of each zone as the information to be printed?


Wouldn't this set a precedent that other things be available as -o?
E.g. -o uuid, -o brand, ...


Yes, it would.

Only introducing '-o datalinks' and never introducing any other -o specifiers 
bit instead moveingto an info subcommand for subsequent ones seems odd.


If you commit to adding other -o specifiers in short order, then I can see 
the benefit of introducing '-o datalinks' as part of IP Instances. If not, 
then this seems like a dead end to me.


Although there isn't an approved case on this yet, I believe there has
been some general agreement that such an option may be useful
(especially since the default "list -v" output is getting rather
wide).

Can we hold off on introducing the "list -l" functionality from this
design until we can resolve how to deal with the more general
observability issue?  Perhaps either through a "zoneadm info" or a
"zoneadm list -o" mechanism?

dsc
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[David . Comay]

I tried the kill and AFAICT root in the global zone can kill a process
in a non-global zone:


OK.  I must be misremembering this.  I thought the restriction was
more complex than that.


Within the global zone, the ability to kill a process in a non-global
zone is controlled by the "proc_zone" privilege.  Normally, only a user
with all privileges will have this ability unless modified via RBAC.

dsc
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[James Carlson]

[EMAIL PROTECTED] writes:
> >> I tried the kill and AFAICT root in the global zone can kill a process
> >> in a non-global zone:
> >
> > OK.  I must be misremembering this.  I thought the restriction was
> > more complex than that.
> 
> Within the global zone, the ability to kill a process in a non-global
> zone is controlled by the "proc_zone" privilege.  Normally, only a user
> with all privileges will have this ability unless modified via RBAC.

Thanks.  ;-}

I _knew_ it wasn't as simple as killing a process in the global zone.

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[Erik Nordmark]

James Carlson wrote:


In some usage models, the global zone administrator "owns"
everything.  Even if he can't directly control things from the global
zone (and must log into the non-global zone to turn services on and
off), he wants to see a view of the system that includes everything.

Do you have an example of that?


I'm not sure I understand the question.  Is CR 6369726 a suitable
example?  If not, then what are you asking?


Sorry, I misread "want" as "need" in the sense of being a show-stopper.


For example, if the administrator of the global zone has Firewall-1
installed, he's going to need to configure IP details in the global
zone.  I don't see how he can do that if he doesn't have access to
them.


Sure. But that is analogous to the external firewall.
We could decide that we want zones/containers/domains on the same system 
to be different, but I think there is value in following a network model 
for network components. After all the network is the computer(tm) ;-)



It depends on the administrator's mental model for the system.


Agreed. My point is that the model for an exclusive-IP zone is different 
in important aspects than the shared-IP zones.


We could try to hide this by pretending that (parts of) ifconfig 
behavior is the same, but I'm far from certain that is a good idea.


But the suggestion (made at PSARC) to use dladm to both
 - assign datalink names to zones
and
 - observe them (in e.g. show-link)

is one which satisfies the consistency between manipulation and 
observation. (And zonecfg can specify things as well; dladm can be used 
to manipulate and observe the running state.)


   Erik

___
zones-discuss mailing list
zones-discuss@opensolaris.org

[zones-discuss] Oracle in zones vs SunCluster HA oracle

[Ulf Björklund]

Hi All,

I'm about to deploy a new platform for about 30+ oracle instances.
These will be Ora 9i to Ora 10g. The availability for these will match
what you'll get from SunCluster HA Oracle agents. (FailOverServices)
The instances will be spread over three to five nodes so one could
manually balance the load. (planned actions)

Would it be preferable to use one zone for each ora-instance instead of
making then HA-aware in the global zone as traditional HA-services?
(Ora in zones might be more integrated in SC3.2)

Some obvious tasks is acctually easier to manage in a zone, like
local users, roles, profiles, system resources and so on.

Any comments and suggestions on the different approach is much appreciated.

/Best Regards
Ulf
 
 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow

[James Carlson]

Erik Nordmark writes:
> > It depends on the administrator's mental model for the system.
> 
> Agreed. My point is that the model for an exclusive-IP zone is different 
> in important aspects than the shared-IP zones.

And in other important aspects it's the same: it's still a single
shared kernel and a single set of hardware resources.

For that reason, I don't believe it's entirely wrong for users to want
to be able to answer questions such as "what addresses are being used
by this node?"

There's a fair argument to be had for a _fully_ virtualized
environment such as Domains or a paravirtualized one such as Xen that
the global view either doesn't exist or is "hard" to obtain.  I think
it's very much harder for that same argument to hold when we're
talking about a single instance of Solaris -- no matter how many
network stacks are involved.

Anyway, as I said at the beginning, I think making ifconfig work this
way would be very hard to do, and likely would not work well.  Though
users often think of ifconfig as the sole way to interact with
networking interfaces (because that's the way it works everywhere but
Solaris), I don't think that's reasonably doable here, even if it's
something that might be wanted.

> We could try to hide this by pretending that (parts of) ifconfig 
> behavior is the same, but I'm far from certain that is a good idea.
> 
> But the suggestion (made at PSARC) to use dladm to both
>   - assign datalink names to zones
> and
>   - observe them (in e.g. show-link)
> 
> is one which satisfies the consistency between manipulation and 
> observation. (And zonecfg can specify things as well; dladm can be used 
> to manipulate and observe the running state.)

Right.  The difference is that the zonecfg is just behaving as a
repository for configuration that properly "belongs" to some other
subsystem, rather than behaving as the configuration tool itself.

(Yeah, there's a fuzzy line here as well.)

-- 
James Carlson, KISS Network<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

[zones-discuss] Re: PSARC/2006/598 Swap resource control; locked memory RM improvements

[Steve Lawrence]

I am working on a new spec.  I have an unanswered question from the
discussion:

> > The "SIZE" column will also be changed to "SWAP" for prstat
> > options a, T, and J, for users, tasks, and projects.
>
> The reason for not changing this column in the default output would be
> helpful.

I have a seperate private interface used by prstat(1m) to get aggregate swap
reserved by users, tasks, projects, and zones.  Default prstat output is
"per-process", and the information is accessed via /proc.

Currently, per-process swap reservation is not counted or made available via
/proc.  From proc(4):

 typedef struct psinfo {
...
size_t pr_size;   /* size of process image in Kbytes */
...

"size of process image" is pretty meaningless.  If we can change "pr_size" to
be "swap reserved by process", then we could change "SIZE" to "SWAP" for all
prstat(1m) output.  Would such a change to psinfo_t be reasonable  If
not, could potentially convert pr_pad1 to pr_swap

-Steve


On Mon, Nov 06, 2006 at 12:13:41PM -0800, Gary Winiger wrote:
> At the request of the project team, I've put this case into waiting need spec.
> When the spec is updated, it will be sent out and the timer reset.
> 
> Gary..
___
zones-discuss mailing list
zones-discuss@opensolaris.org

[zones-discuss] error installing zone

[Gregory Edwards - Software Support]

Customer is install a zone on a SAN running EMC.

zoneadm -z install preparing to install zone 
Checking  file system on device  to be mounted at 


ERROR:tai  of  failed: exit status 33:
run fsck manuallyERROR: file system  on device /dev/rdsk/emcpower12a  is 
inconsistent and cannot be mounted
zone failed with exit code 74


--
  * Gregory D Edwards *
Technical Support Engineer - Operating Systems
*Sun Microsystems *
Phone: 1 800 872 4786 ref case #
Email: [EMAIL PROTECTED]
Working Hours: 0900-1800 Mon-Fri MST


___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Re: [networking-discuss] Re:[crossbow-discuss]Design review of IP Instances part of Crossbow

[Darren Reed]

From: "James Carlson" <[EMAIL PROTECTED]>

Erik Nordmark writes:

> It depends on the administrator's mental model for the system.

Agreed. My point is that the model for an exclusive-IP zone is different
in important aspects than the shared-IP zones.


And in other important aspects it's the same: it's still a single
shared kernel and a single set of hardware resources.

For that reason, I don't believe it's entirely wrong for users to want
to be able to answer questions such as "what addresses are being used
by this node?"

...

Anyway, as I said at the beginning, I think making ifconfig work this
way would be very hard to do, and likely would not work well.  Though
users often think of ifconfig as the sole way to interact with
networking interfaces (because that's the way it works everywhere but
Solaris), I don't think that's reasonably doable here, even if it's
something that might be wanted.


So how would you propose a system administrator, in the global
zone, bring together all of the network addresses configured for
his machine?

Does this now require zlogin and a loop through all of the zones
that are currently booted?

Will this be "too hard" for those that want to do it?

Thinking on this, would it be "nice" if there was some special command
line switch for the likes of netstat/ifconfig and others that caused them to
iterate through all of the present stack instances and report on them?

Darren

___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] [Fwd: Reminder: Design review of IP Instances part of Crossbow]]

[Edward Pilatowicz]

On Mon, Nov 06, 2006 at 11:41:56AM -0800, Erik Nordmark wrote:
> Edward Pilatowicz wrote:
>
> [You brought up an issue with /etc/hostname.* etc being ignored when a
> shared-IP zone is booted.]
>
> >perhaps some kind of warning message should be generated in this
> >scenario instead?
> >
> >something like:
> > Ignoring zone network configuration specified: /etc/hostname.bge0
> > Current network configuration is dictated by the global zone.
> > To use the network configuration specified within this zone it
> > must have an exclusive-IP instance allocated to it by the global
> > zone.
>
> This is an issue in S10 at two levels:
> 1. The /etc/hostname. and related files are ignored when a zone
> is booted.
> 2. Any IP configuration information in $ZROOT/etc/sysidcfg is ignored by
> sysidtool
>
> It might be that IP Instances makes this more of an issue, although I'm
> not certain it will, but in any case the issue is with the original
> shared-IP stack. (Of course, this is far from the only issue with the
> shared-IP stack.)
>

well, i see it as a new issue because previously we had one consistent
behavior.  (always ignore ip configuration files.)  now we're going to
have two different behaviors based on an option that someone can set in
zonecfg.  where this can gets confusing is that this is an option that
they can change at any time in zonecfg and they may not realize the
full extent/impact of what they've done.  hence i thought it might be
good to make it obvious that we thing something is not quite right.

if i've created an exclusive-IP zone and then i change it to a shared
IP zone but don't specify IP configuration info (and i expect it
to get this configuration in the same way it used to) i'm going to be
confused as to why things aren't working.

> I don't know what the best way is to proceed on this. One way is to just
> file CRs on the share-IP stack (smf scripts and sysidtool).
> But medium term it might make sense to instead spend our time on
> aggressively moving away from the shared-IP stack (and maybe even
> ripping out that code in our lifetimes) by making sure that the
> exclusive-IP stack can satisfy the same needs as the shared-IP stack. IP
> Instances is a bey building block for this, but we also need some
> additional pieces (some of which are under way)
>  - vnic support to get the same type of sharing of the "wire" as with
> the shared-IP stack
>  - security (perhaps in the form of GLD-level filtering) to contain
> exclusive-IP zones towards the network (prevent ARP spoofing, redirect
> spoofing, RIP spoofing, etc) since ARP spoofing is prevented for
> shared-IP zones
>  - think about scalable/centralizable configuration of IP parameters
> for zones. I think the answer is related to DHCP; perhaps having easy
> configurations where the global zone can be a DHCP server (and NAT?) for
> the non-global zones on the same machine. We have the building blocks
> for this, but we need to better understand the identity of a zone as it
> relates to DHCP before we proceed.
>
> So long answer to a short question. Adding warning messages doesn't seem
> to help us get to where we need to go.
>

i think that with vnics this would be a really cool possibility and
would help simplify the new choose-you-ip-stack-type zones model and
also make global and non-global zone behavior more consistent.

are the any proposals for how exclusive IP instances could be used
to replace shared-IP stacks?  it would be helpfull to see this to
understand what operations would be permitted/restricted/required
within zones if we were to do this.

>
> >nit: in zonecfg it's "ip-type" were as above there's no dash.
>
> I realized that. We'll make them consistent.
>
> >i looked into it a bit more and as it turns out in linux network devices
> >don't actually have any /dev entries.  but we can't simply tell non-native
> >brands not to map exclusive-IP network devices because this could break
> >other zones.  (think sn1, belinix, nexenta, etc.)
> >
> >so here's a question.  in an exclusive-IP zone, do we have to have
> >network /dev entries in to be able to configure network interfaces?
> >or can all the necessary configuration be done via socket operations?
>
> No.
> sockets are implemented using devices (see /etc/sock2path), and ifconfig
> plumb is implemented using DLPI devices.
>

so for ifconfig, we need to have access to the devices, right?

> >i guess if we need to have access to the device nodes then the easiest
> >thing to do will be to simply map them in and hopefully linux apps will
> >ignore them.  if linux apps don't ignore them then we'll have to
> >create /dev and /native/dev as seperate namespaces.  (currently
> >they are the same.)
>
> If there is a /dev/bge1 in a lx zone, presumably it doesn't upset
> anything. Or are there applications which try to do something to
> everything the find in /dev?
>

well, glibc:ttyname() actually traveres all of /dev looking for
devices that match the passed in f