It indicates the reloading sequence attribute of the image.
For the device which support dual image:
If the value is 'main(1)',the image will be the first image
in the next reloading procedure. If the value is 'backup(1)',
the image will be used if the main image fails. If the value
is 'none(3)',the image will not be used in the next reloading
procedure.
At the same time,you also can specify the main image by
h3cSysReloadImage in h3cSysReloadScheduleTable. When reload action
is executing, the corresponding image will become main image.If the
image is diffrent from previous main image,the previous main image
will not be main image again. And the image table will update with
this variation. Vice versa, if you have defined the reload schedule
, and then you define a new main image through h3cSysImageType when you
are waiting the reload schedule to be executed, the real main image
will be the latest one.
It is strongly suggested to define the main image here, not by h3cSysReloadImage
in h3cSysReloadScheduleTable.
There are some rules for setting the value of h3cSysImageType:
a)When a new image file is defined as 'main' or 'backup' file,the h3cSysImageType
of old 'main' or 'backup' file will automatically be 'none'.
b)It is forbidden to set 'none' attribute manually.
c)It is forbidden to set 'backup' attribute to the 'main' image directly.The
'main' image file MUST be set 'none' by setting another new 'main' image,then
it can be set to 'backup' attribute.
The following table describes wheather it is ok to set to another state
directly from original state.
+
| set to | set to | set to |
| | | |
original | 'main' | 'backup' | 'none' |
state | | | |
| | | |
main | yes | no | no |
| | | |
| | | |
| | | |
backup | yes | yes | no |
| | | |
| | | |
| | | |
none | yes | yes | no |
| | | |
If there is one main image in the sytem,one row of H3cSysReloadScheduleEntry
whose h3cSysReloadImage is equal to the main image's h3cSysImageIndex will be
created automatically.
For the device which doesn't support dual image(main/backup):
If the device doesn't support dual image,and has not defined
the image sequence of reloading by 'main' and 'backup',
this value will remain 'none(3)',and you must specify one image
by h3cSysReloadImage in h3cSysReloadScheduleTable.
Parsed from file h3c-sys-man.mib.txt
Company: huawei
Module: H3C-SYS-MAN-MIB
Vendor: Huawei
Module: H3C-SYS-MAN-MIB (h3c-sys-man.mib)
Type: TABULAR
Access: read-write
Syntax: INTEGER
Automatically extracted from www.mibdepot.com
h3cSysImageType OBJECT-TYPE SYNTAX INTEGER { main(1), backup(2), none(3) } MAX-ACCESS read-write STATUS current DESCRIPTION " It indicates the reloading sequence attribute of the image. For the device which support dual image: If the value is 'main(1)',the image will be the first image in the next reloading procedure. If the value is 'backup(1)', the image will be used if the main image fails. If the value is 'none(3)',the image will not be used in the next reloading procedure. At the same time,you also can specify the main image by h3cSysReloadImage in h3cSysReloadScheduleTable. When reload action is executing, the corresponding image will become main image.If the image is diffrent from previous main image,the previous main image will not be main image again. And the image table will update with this variation. Vice versa, if you have defined the reload schedule , and then you define a new main image through h3cSysImageType when you are waiting the reload schedule to be executed, the real main image will be the latest one. It is strongly suggested to define the main image here, not by h3cSysReloadImage in h3cSysReloadScheduleTable. There are some rules for setting the value of h3cSysImageType: a)When a new image file is defined as 'main' or 'backup' file,the h3cSysImageType of old 'main' or 'backup' file will automatically be 'none'. b)It is forbidden to set 'none' attribute manually. c)It is forbidden to set 'backup' attribute to the 'main' image directly.The 'main' image file MUST be set 'none' by setting another new 'main' image,then it can be set to 'backup' attribute. The following table describes wheather it is ok to set to another state directly from original state. + | set to | set to | set to | | | | | original | 'main' | 'backup' | 'none' | state | | | | | | | | main | yes | no | no | | | | | | | | | | | | | backup | yes | yes | no | | | | | | | | | | | | | none | yes | yes | no | | | | | If there is one main image in the sytem,one row of H3cSysReloadScheduleEntry whose h3cSysReloadImage is equal to the main image's h3cSysImageIndex will be created automatically. For the device which doesn't support dual image(main/backup): If the device doesn't support dual image,and has not defined the image sequence of reloading by 'main' and 'backup', this value will remain 'none(3)',and you must specify one image by h3cSysReloadImage in h3cSysReloadScheduleTable. " ::= { h3cSysImageEntry 5 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.2011.10.2.3.1.4.2.1.1 | h3cSysImageIndex | 0 | 0 | There are two parts for the index depicted as follows: 31 15 0 +++++++++++++++++++++++++++++++++++ + p… |
| 1.3.6.1.4.1.2011.10.2.3.1.4.2.1.2 | h3cSysImageName | 0 | 0 | The file name of the image. It MUST NOT contain the path of the file. |
| 1.3.6.1.4.1.2011.10.2.3.1.4.2.1.3 | h3cSysImageSize | 0 | 0 | The size of the specified image. |
| 1.3.6.1.4.1.2011.10.2.3.1.4.2.1.4 | h3cSysImageLocation | 0 | 0 | The directory path of the image. It's form should be the same as what defined in file system. Currently it is defined as follows:… |