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
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
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.
[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,
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
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.
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
[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
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
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
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
Customer is install a zone on a SAN running EMC.
zoneadm -z install preparing to install zone
Checking ufs file system on device /dev/rdsk/emcpower12a to be mounted at /opt/zones/zonename/root
ERROR:tai usr/lib/fs/fsck of /dev/rdsk/emcpower12a failed: exit status 33:
run fsck manuallyERROR:
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:
13 matches
Mail list logo
