[OpenAFS] Opneafs in solaris 9 containers

Andersson, Johan johan.andersson@hp.com
Wed, 12 Nov 2008 11:45:05 +0000


        Hi again

        /etc/name_to_sysnum on selix030lte04 have "afs 65"
        //JA

-----Original Message-----
From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org=
] On Behalf Of Andersson, Johan
Sent: den 12 november 2008 12:35
To: Derrick Brashear
Cc: openafs-info@openafs.org
Subject: RE: [OpenAFS] Opneafs in solaris 9 containers

        /ete/name_to_sysname on selix030lte04 have "afs 65"
        //JA

-----Original Message-----
From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org=
] On Behalf Of Derrick Brashear
Sent: den 11 november 2008 14:35
To: openafs-info@openafs.org
Subject: Re: [OpenAFS] Opneafs in solaris 9 containers

Well, it'd still be wrong, but, is /etc/name_to_sysnum in the solaris
9 host modified? If not, modifying and rebooting should make things "better=
" but not right.

On Tue, Nov 11, 2008 at 2:57 AM, Andersson, Johan <johan.andersson@hp.com> =
wrote:
>        Hi Agin
>
> More info about the problem with Openafs in solaris 9 containers:
>
> The global host is selix030gh
> # uname -a
> SunOS selix030gh 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire-V445
> # # zoneadm list -icv
>  ID NAME             STATUS     PATH                           BRAND    I=
P
>   0 global           running    /                              native   s=
hared
>   1 selix030lte01    running    /export/vm/selix030lte01       native   s=
hared
>   2 selix030lte03    running    /export/vm/selix030lte03       native   s=
hared
>   3 selix030lte02    running    /export/vm/selix030lte02       native   s=
hared
>   4 selix030lte04    running    /export/vm/selix030lte04       solaris9 s=
hared
>   - vgtemplate       installed  /export/vm/vgtemplate          native   s=
hared
> #
>
> selix030lte04 [8:38am] [/usr/afsws/bin] -> fs sysname Bad system call
> selix030lte04 [8:38am] [/usr/afsws/bin] -> uname -a SunOS
> selix030lte04 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Fire-V445
> selix030lte04 [8:40am] [/usr/afsws/bin] ->
>
> # zonecfg -z selix030lte04
> zonecfg:selix030lte04> info
> zonename: selix030lte04
> zonepath: /export/vm/selix030lte04
> brand: solaris9
> autoboot: true
> bootargs:
> pool:
> limitpriv:
> scheduling-class:
> ip-type: shared
> fs:
>        dir: /afs
>        special: /afs
>        raw not specified
>        type: lofs
>        options: []
> net:
>        address: XX.XX.XX.XX
>        physical: bge0
> attr:
>        name: hostid
>        type: string
>        value: XXXXXX
> attr:
>        name: machine
>        type: string
>        value: sun4u
> zonecfg:selix030lte04>
>
> selix030lte01 [8:40am] [/usr/afsws/bin] -> fs sysname Current sysname
> is 'sun4x_510'
> selix030lte01 [8:40am] [/usr/afsws/bin] -> uname -a SunOS
> selix030lte01 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire-V445
> selix030lte01 [8:40am] [/usr/afsws/bin] ->
>
> # zonecfg -z selix030lte01
> zonecfg:selix030lte01> info
> zonename: selix030lte01
> zonepath: /export/vm/selix030lte01
> brand: native
> autoboot: true
> bootargs:
> pool:
> limitpriv:
> scheduling-class:
> ip-type: shared
> inherit-pkg-dir:
>        dir: /lib
> inherit-pkg-dir:
>        dir: /platform
> inherit-pkg-dir:
>        dir: /sbin
> inherit-pkg-dir:
>        dir: /usr
> fs:
>        dir: /afs
>        special: /afs
>        raw not specified
>        type: lofs
>        options: []
> net:
>        address: XX.XX.XX.XX
>        physical: bge0
> zonecfg:selix030lte01>
>
>        Best Regards
>
>        //JA
>
>
> -----Original Message-----
> From: Derrick Brashear [mailto:shadow@gmail.com]
> Sent: den 6 november 2008 16:24
> To: Chas Williams (CONTRACTOR)
> Cc: Douglas E. Engert; Andersson, Johan; openafs-info@openafs.org
> Subject: Re: [OpenAFS] Opneafs in solaris 9 containers
>
> Seems like a special case of exporter objects for virtualized platforms m=
ight work here.
>
> On Thu, Nov 6, 2008 at 10:11 AM, Chas Williams (CONTRACTOR) <chas@cmf.nrl=
.navy.mil> wrote:
>> In message <491305E8.9080401@anl.gov>,"Douglas E. Engert" writes:
>>>The AFS cache manager is not aware of zones, and I would not expect
>>>it to be aware of containers either.  I suspect that the container
>>>code does not know anything about @sys and may be producing the
>>>output of pwd, If a file access needed, the server kernel with AFS
>>>does map it to sun4x_510.
>>
>> you might be able to fix this without too much trouble.  you can get
>> the zone for a vnode, VTOZ.  hopefully containers would have
>> something similar (or just use the same mechanism).  you would then
>> need to find a way to figure out what kernel is running in the
>> zone/container or just let the cache manager set a sysname on a per zone=
 basis.
>>
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
>
>
>
> --
> Derrick
>



--
Derrick
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info