crossbow discuss - Apr 2007 - failure mode when exclusive ip-type interface is not available

I have noticed and was discussing with some folks that when a zone is 
configured with an exclusive ip-type, and an interface assigned to that 
zone is not available, there is a message to that effect when issuing 
zoneadm ... boot in the global zone, but none in the non-global zone. Or on 
a reboot, there is a message to syslog/console.

The test case had the interface just plumbed in the global zone, after the 
zone was configured.

A point was made that this behavior is not consistent with other resouce 
issues when booting a zone. If a zone is given some
''dedicated-cpus'' and
there are not sufficient CPUs available, the zone will not boot.

Is this intended behavior? Is it worth considering having the behavior be 
that the zone does not boot if a network resource is not available, as is 
the case for [at least] CPUs? Or consider a variable that indicated the 
minimun available interfaces? Or maybe something else.

In my case the interface was occupied by the global zone. But other failure 
modes included failed NICs, interfaces that were mis-configured, or 
interfaces that DRed out (administratively or via FMA).

Thanks
Steffen

Yes, it is intended behavior, cpu is, en, cpu, physical machines cannot
boot if cpu or mainboard or even, memory fail, but why a machine would
refuse to boot when one or [even] all of the nic-s are unavailable? :-)

Best,

Donghai.

----- Original Message -----
From: Steffen Weiberle <Steffen.Weiberle at Sun.COM>
Date: Tuesday, April 24, 2007 8:37 pm
Subject: [crossbow-discuss] failure mode when exclusive ip-type interface is not
available
To: crossbow-discuss at opensolaris.org
> I have noticed and was discussing with some folks that when a zone 
> is 
> configured with an exclusive ip-type, and an interface assigned to 
> that 
> zone is not available, there is a message to that effect when 
> issuing 
> zoneadm ... boot in the global zone, but none in the non-global 
> zone. Or on 
> a reboot, there is a message to syslog/console.
> 
> The test case had the interface just plumbed in the global zone, 
> after the 
> zone was configured.
> 
> A point was made that this behavior is not consistent with other 
> resouce 
> issues when booting a zone. If a zone is given some ''dedicated-
> cpus'' and 
> there are not sufficient CPUs available, the zone will not boot.
> 
> Is this intended behavior? Is it worth considering having the 
> behavior be 
> that the zone does not boot if a network resource is not available, 
> as is 
> the case for [at least] CPUs? Or consider a variable that indicated 
> the 
> minimun available interfaces? Or maybe something else.
> 
> In my case the interface was occupied by the global zone. But other 
> failure 
> modes included failed NICs, interfaces that were mis-configured, or 
> interfaces that DRed out (administratively or via FMA).
> 
> Thanks
> Steffen
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>

Hi Donghai,

Dong-Hai Han wrote On 04/24/07 10:31,:
> Yes, it is intended behavior, cpu is, en, cpu, physical machines cannot
> boot if cpu or mainboard or even, memory fail, but why a machine would
> refuse to boot when one or [even] all of the nic-s are unavailable? :-)
1. what use is the zone if it can''t be reached?

2. the behavior is different for different types of resources

Note, that the zone will not boot if sufficient CPUs are not available. If 
the zone has been configured to have 2-4 CPUs, and only 1 is available, it 
will fail to boot. It could still run, but the chosen behavior is to not 
run it. I am suggesting a similar facility should be in place for network 
resources.

Steffen
> 
> Best,
> 
> Donghai.
> 
> ----- Original Message -----
> From: Steffen Weiberle <Steffen.Weiberle at Sun.COM>
> Date: Tuesday, April 24, 2007 8:37 pm
> Subject: [crossbow-discuss] failure mode when exclusive ip-type interface
is not available
> To: crossbow-discuss at opensolaris.org
> 
> 
>>I have noticed and was discussing with some folks that when a zone 
>>is 
>>configured with an exclusive ip-type, and an interface assigned to 
>>that 
>>zone is not available, there is a message to that effect when 
>>issuing 
>>zoneadm ... boot in the global zone, but none in the non-global 
>>zone. Or on 
>>a reboot, there is a message to syslog/console.
>>
>>The test case had the interface just plumbed in the global zone, 
>>after the 
>>zone was configured.
>>
>>A point was made that this behavior is not consistent with other 
>>resouce 
>>issues when booting a zone. If a zone is given some ''dedicated-
>>cpus'' and 
>>there are not sufficient CPUs available, the zone will not boot.
>>
>>Is this intended behavior? Is it worth considering having the 
>>behavior be 
>>that the zone does not boot if a network resource is not available, 
>>as is 
>>the case for [at least] CPUs? Or consider a variable that indicated 
>>the 
>>minimun available interfaces? Or maybe something else.
>>
>>In my case the interface was occupied by the global zone. But other 
>>failure 
>>modes included failed NICs, interfaces that were mis-configured, or 
>>interfaces that DRed out (administratively or via FMA).
>>
>>Thanks
>>Steffen
>>_______________________________________________
>>crossbow-discuss mailing list
>>crossbow-discuss at opensolaris.org
>>http://opensolaris.org/mailman/listinfo/crossbow-discuss
>>

Steffen Weiberle wrote:
> A point was made that this behavior is not consistent with other resouce 
> issues when booting a zone. If a zone is given some
''dedicated-cpus'' and
> there are not sufficient CPUs available, the zone will not boot.
 >
> Is this intended behavior? Is it worth considering having the behavior 
> be that the zone does not boot if a network resource is not available, 
> as is the case for [at least] CPUs? Or consider a variable that 
> indicated the minimun available interfaces? Or maybe something else.
The consistency has actually been driven from how network interfaces 
work in the global zone.
When the global zone boots and tries to use e.g. bgeN and that NIC 
doesn''t exist, the boot continues.
In S10 FCS the behavior for zones was different in that a zone would 
fail to boot if the network interface wasn''t present. This was fixed in
a S10 update so that the zone would boot without the missing network 
interface. (And emit a warning.)

For exclusive-IP zones we are consistent with that; the zone boots even 
if the network interface isn''t available (and emit a warning.)

    Erik

Erik Nordmark wrote:
> Steffen Weiberle wrote:
> 
>> A point was made that this behavior is not consistent with other 
>> resouce issues when booting a zone. If a zone is given some 
>> ''dedicated-cpus'' and there are not sufficient CPUs
available, the zone
>> will not boot.
>  >
>> Is this intended behavior? Is it worth considering having the behavior 
>> be that the zone does not boot if a network resource is not available, 
>> as is the case for [at least] CPUs? Or consider a variable that 
>> indicated the minimun available interfaces? Or maybe something else.
> 
> The consistency has actually been driven from how network interfaces 
> work in the global zone.
> When the global zone boots and tries to use e.g. bgeN and that NIC 
> doesn''t exist, the boot continues.
> In S10 FCS the behavior for zones was different in that a zone would 
> fail to boot if the network interface wasn''t present. This was
fixed in
> a S10 update so that the zone would boot without the missing network 
> interface. (And emit a warning.)
> 
> For exclusive-IP zones we are consistent with that; the zone boots even 
> if the network interface isn''t available (and emit a warning.)
Thanks Erik, that consistency makes sense.  Is the warning emitted to the GZ, 
the NGZ, or both?  I think that the GZ admin would want to know, so that the 
problem can be fixed.  Also, the NGZ admin would want to know, to avoid 
discovering a downstream symptom and facing the task of troubleshooting the 
symptom.



--------------------------------------------------------------------------
Jeff VICTOR              Sun Microsystems            jeff.victor @ sun.com
OS Ambassador            Sr. Technical Specialist
Solaris 10 Zones FAQ:    http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------

Hi Erik,

I see what you are saying. That makes sense. I am checking if there is any 
indication within the zone that a network interface is missing.

Steffen

Erik Nordmark wrote On 04/24/07 12:52,:
> Steffen Weiberle wrote:
> 
>> A point was made that this behavior is not consistent with other 
>> resouce issues when booting a zone. If a zone is given some 
>> ''dedicated-cpus'' and there are not sufficient CPUs
available, the zone
>> will not boot.
> 
>  >
> 
>> Is this intended behavior? Is it worth considering having the behavior 
>> be that the zone does not boot if a network resource is not available, 
>> as is the case for [at least] CPUs? Or consider a variable that 
>> indicated the minimun available interfaces? Or maybe something else.
> 
> 
> The consistency has actually been driven from how network interfaces 
> work in the global zone.
> When the global zone boots and tries to use e.g. bgeN and that NIC 
> doesn''t exist, the boot continues.
> In S10 FCS the behavior for zones was different in that a zone would 
> fail to boot if the network interface wasn''t present. This was
fixed in
> a S10 update so that the zone would boot without the missing network 
> interface. (And emit a warning.)
> 
> For exclusive-IP zones we are consistent with that; the zone boots even 
> if the network interface isn''t available (and emit a warning.)
> 
>     Erik

Jeff Victor wrote On 04/24/07 13:27,:
> Erik Nordmark wrote:
> 
>> Steffen Weiberle wrote:
>>
>>> A point was made that this behavior is not consistent with other 
>>> resouce issues when booting a zone. If a zone is given some 
>>> ''dedicated-cpus'' and there are not sufficient
CPUs available, the
>>> zone will not boot.
>>
>>  >
>>
>>> Is this intended behavior? Is it worth considering having the 
>>> behavior be that the zone does not boot if a network resource is
not
>>> available, as is the case for [at least] CPUs? Or consider a
variable
>>> that indicated the minimun available interfaces? Or maybe something
>>> else.
>>
>>
>> The consistency has actually been driven from how network interfaces 
>> work in the global zone.
>> When the global zone boots and tries to use e.g. bgeN and that NIC 
>> doesn''t exist, the boot continues.
>> In S10 FCS the behavior for zones was different in that a zone would 
>> fail to boot if the network interface wasn''t present. This was
fixed
>> in a S10 update so that the zone would boot without the missing 
>> network interface. (And emit a warning.)
>>
>> For exclusive-IP zones we are consistent with that; the zone boots 
>> even if the network interface isn''t available (and emit a
warning.)
> 
> 
> Thanks Erik, that consistency makes sense.  Is the warning emitted to 
> the GZ, the NGZ, or both?  I think that the GZ admin would want to know, 
> so that the problem can be fixed.  Also, the NGZ admin would want to 
> know, to avoid discovering a downstream symptom and facing the task of 
> troubleshooting the symptom.
I can answer that, now.

If there is no file to plumb the interface in the zone, there is no 
indication in the zone. Without an /etc/hostname*, the only error message 
is in the terminal session if the boot is due to the issuance of 
''zoneadm... [re]boot'', or to the console if it is due to
another action
(autoboot, reboot within the zone).

With an /etc/hostname, their is a message in the zone console, but none in 
/var/adm/messages. However, this is also consistent with the global zone. 
If you have /etc/hostname* in it for an interface that does not exist, the 
only message goes to the console, but not to /var/adm/messages.

Steffen
> --------------------------------------------------------------------------
> Jeff VICTOR              Sun Microsystems            jeff.victor @ sun.com
> OS Ambassador            Sr. Technical Specialist
> Solaris 10 Zones FAQ:    http://www.opensolaris.org/os/community/zones/faq
> --------------------------------------------------------------------------

> With an /etc/hostname, their is a message in the zone console, but none in 
 > /var/adm/messages. However, this is also consistent with the global zone. 
 > If you have /etc/hostname* in it for an interface that does not exist, the
 > only message goes to the console, but not to /var/adm/messages.

FWIW, there''s also a bug I noticed recently in the boot scripts that
will
cause them to only report the first missing/failed interface identified;
see 6549957.

-- 
meem

Steffen Weiberle wrote:
> If there is no file to plumb the interface in the zone, there is no 
> indication in the zone. Without an /etc/hostname*, the only error 
> message is in the terminal session if the boot is due to the issuance of 
> ''zoneadm... [re]boot'', or to the console if it is due to
another action
> (autoboot, reboot within the zone).
> 
> With an /etc/hostname, their is a message in the zone console, but none 
> in /var/adm/messages. However, this is also consistent with the global 
> zone. If you have /etc/hostname* in it for an interface that does not 
> exist, the only message goes to the console, but not to /var/adm/messages.
Does svcs -x in the NGZ show anything?
(Perhaps network/physical should be in maintenance in this case.)

    Erik