Thanks,
Vincent
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Ellard Roush writes:
> Thanks for explaining about how the routing situation changes dynamically.
> However, we have been aware of that for a long time.
>
> Sun Cluster (SC) is a High Availability product.
> We have customers that want recovery to occur in less than 2 seconds.
> While we have not
Steve Lawrence wrote:
> Looks like the environment contained in /etc/default/init is
> read and set
> by startd and init. Since zlogin'ed processes are not child
> of startd or init
> in the zone, they do not have these environment settings.
>
> Given brands, to fix this, we would need to add a
Hi James,
It is already well known that routes come and go.
It is already well known that the way to determine
whether a destination is reachable is to attempt to
contact that destination.
That is NOT the issue that I am raising.
We have seen the following PROBLEM.
Our code has a dependency upon
On Wed, Apr 02, 2008 at 11:11:12AM -0400, Moore, Joe wrote:
> Steve Lawrence wrote:
> > Looks like the environment contained in /etc/default/init is
> > read and set
> > by startd and init. Since zlogin'ed processes are not child
> > of startd or init
> > in the zone, they do not have these envi
Matthew Taylor wrote:
> Apologies if my search-fu failed me and the answer is out there.
>
> I have a box with 1 hme and 8 qfe interfaces. I would normally used
> exclusive IP zones, but that is not possible with these non-gldv3 driven
> interfaces, so I am forced to use shared IP zones.
>
>
Ellard Roush writes:
> If we make the code sleep long enough for Solaris routing to
> complete initialization, then after a failed attempt
> to connect, then retries work whenever the route becomes
> available. The problem is that Solaris routing goes into
> an error state when we attempt to connec
Apologies if my search-fu failed me and the answer is out there.
I have a box with 1 hme and 8 qfe interfaces. I would normally used exclusive
IP zones, but that is not possible with these non-gldv3 driven interfaces, so I
am forced to use shared IP zones.
hme0 is configured on the host with
Matthew Taylor wrote:
> Do you know if plumbing all the qfe's without assigning an IP address will
> persist across reboots of the base system? Never tried that on Solaris
> (works on LINUX iirc, but you have to enter the info in a script).
It will not persist. An empty /etc/hostname.qfe0 will
Thank you, and to those who replied off line as well. I will try it out and
report back on my success (or not) in the morning.
It does strike me that this should be in the docs. I have gone through
817-1592-15, the Zones admin guide, and find little to nothing on what the
configuration of the
Do you know if plumbing all the qfe's without assigning an IP address will
persist across reboots of the base system? Never tried that on Solaris (works
on LINUX iirc, but you have to enter the info in a script).
This message posted from opensolaris.org
__
Hi James,
James Carlson wrote:
> Ellard Roush writes:
>> If we make the code sleep long enough for Solaris routing to
>> complete initialization, then after a failed attempt
>> to connect, then retries work whenever the route becomes
>> available. The problem is that Solaris routing goes into
>> a
Matthew Taylor writes:
> Do you know if plumbing all the qfe's without assigning an IP address will
> persist across reboots of the base system? Never tried that on Solaris
> (works on LINUX iirc, but you have to enter the info in a script).
This will make plumbing persist across reboot for qfe
Matthew Taylor wrote:
> Thank you, and to those who replied off line as well. I will try it out and
> report back on my success (or not) in the morning.
>
> It does strike me that this should be in the docs. I have gone through
> 817-1592-15, the Zones admin guide, and find little to nothing o
James Carlson wrote:
> Matthew Taylor writes:
>> Do you know if plumbing all the qfe's without assigning an IP address will
>> persist across reboots of the base system? Never tried that on Solaris
>> (works on LINUX iirc, but you have to enter the info in a script).
>
> This will make plumbing
Is there a way to convert a sparse zone to root or just remove inherited
lofs to GZ?
I have a sparse zone I'd like to have it's own /usr
thanks
___
zones-discuss mailing list
zones-discuss@opensolaris.org
On Wed 02 Apr 2008 at 09:06PM, Morris Hooten wrote:
> Is there a way to convert a sparse zone to root or just remove inherited
> lofs to GZ?
>
> I have a sparse zone I'd like to have it's own /usr
Morris,
At present there is no way to convert. But this is a use case I will
keep in mind as we d
17 matches
Mail list logo
