Hi Guys,


http://www.wuppdich.com/combined_error.txt

(I'm providing a separate link to my df -h and zfs list output because
there is
too much of it to put in an email.)


I suspect I'm missing some zfs mountpoints from within my localzone.
The localzone loopback
mounts globalzone's filesystem. Both are supposed to mount rpool/opt
upon /
and rpool/output01 upon /output01 respectively.


The global zone appears to be doing this just fine. But the local zone
can't do it
and appears to be mounting its /opt and /output01 filesystems on /

I'm currently working through through the issues and would appreciate
inciteful comments.


Regards,

PaulB

On 08/ 9/10 05:35 AM, Paul Branon wrote:
> Hi Guys,
>
> I suspect I'm missing some zfs mountpoints from within my localzone.
> The localzone loopback
> mounts globalzone's filesystem. Both are supposed to mount rpool/opt
> upon /
> and rpool/output01 upon /output01 respectively.
>
>
> The global zone appears to be doing this just fine. But the local zone
> can't do it
> and appears to be mounting its /opt and /output01 filesystems on /
>
> I'm currently working through through the issues and would appreciate
> inciteful comments.

Post the zone's config.

-- 
Ian Collins

On Aug 8, 8:51=A0pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 08/ 9/10 05:35 AM, Paul Branon wrote:
>
> > Hi Guys,
>
> > I suspect I'm missing some zfs mountpoints from within my localzone.
> > The localzone loopback
> > mounts globalzone's filesystem. Both are supposed to mount rpool/opt
> > upon /
> > and rpool/output01 upon /output01 respectively.
>
> > The global zone appears to be doing this just fine. But the local zone
> > can't do it
> > and appears to be mounting its /opt and /output01 filesystems on /
>
> > I'm currently working through through the issues and would appreciate
> > inciteful comments.
>
> Post the zone's config.
>
> --
> Ian Collins

Hi Ian,

The info you need is all here:
http://www.wuppdich.com/combined_error.txt

On 08/ 9/10 07:54 AM, Paul Branon wrote:
> On Aug 8, 8:51 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 08/ 9/10 05:35 AM, Paul Branon wrote:
>>
>>> Hi Guys,
>>
>>> I suspect I'm missing some zfs mountpoints from within my localzone.
>>> The localzone loopback
>>> mounts globalzone's filesystem. Both are supposed to mount rpool/opt
>>> upon /
>>> and rpool/output01 upon /output01 respectively.
>>
>>> The global zone appears to be doing this just fine. But the local zone
>>> can't do it
>>> and appears to be mounting its /opt and /output01 filesystems on /
>>
>>> I'm currently working through through the issues and would appreciate
>>> inciteful comments.
>>
>> Post the zone's config.
>
> Hi Ian,
>
> The info you need is all here:
> http://www.wuppdich.com/combined_error.txt

You would have been better off posting it here.

Anyway, I don't see your problem.  You have one dataset assigned to the 
zone, which has to exist otherwise the zone install would have failed.

add dataset
   set name=rpool/zonedata/localzone01
end

You will not be able to see any other ZFS filesystems created in the 
global zone.  If you want to see them as regular filesystems, loop-back 
mount them.

You have one filesystem loop-back mounted:

add fs
   set dir=/output01
   set special=/output01/zone
   set type=lofs
   set options=[rw]
end

That appears to be OK as well.


-- 
Ian Collins

Hi Ian,

Yes, it's a really difficult problem to spot. But, put simply, both
the global zone and the local zone have various partitions which act
as mountpoints for the zfs filesystems and they are

(a)
rpool/home mounted on /home
rpool/opt mounted on /opt
rpool/output1 mounted on /output01
etc, etc,etc
you see them all if you look at the output here:
http://www.wuppdich.com/combined_error.txt

(b)
But, the local zone is behaving badly and not mounting its /opt or /
output01
filesystems properly. (And I think I know why. I think it's because it
has not been
configured to mount rpool/opt on /opt or rpool/output01 on /output01
(ie the guy who wrote the scripts forgot that bit, and has been doing
that bit by
hand, I guess.) But the scripts were passed to me and I'd never run
them before
and someone said "hey. those new local zones don't mount /opt or /
output01
as separate partitions they just write that data straight to /
(which since on the globalzone is zonepath /zoneroot/localzone01/root/
will amount to /zoneroot/localzone01/root/output01 and
/zoneroot/localzone01/root/opt respectively.

And what he said was, hey! That data shouldn't be there. It should be
somewhere else, (though he didn't say where else it should be.) But,
looking at all of the other localzone01 mountpoints would suggest that
the data should have been written to rpool/zonedata/serverdb01/opt
rpool/zonedata/serverdb/output01 respectively, (following the
convention of where the other rpool/zonedata filesystem data is
being written to.

But when I think this through it occurs to me that rpool/ data in
the localzone is all mounted loopback from the global zone from
/zoneroot/localzone01


So it makes me wonder if any data was actually written in the wrong
place at all, or if in reality all the guy can legitimately complain
about
is that the filesystems are being mounted in the wrong place in the
local zone. And the mountpoints need to be fixed.

I'm not 100% sure which of us is right, me or him.

Cheers,

Paulb

Please keep context!

On 08/ 9/10 09:08 AM, Paul Branon wrote:
> Hi Ian,
>
> Yes, it's a really difficult problem to spot. But, put simply, both
> the global zone and the local zone have various partitions which act
> as mountpoints for the zfs filesystems and they are
>
> (a)
> rpool/home mounted on /home
> rpool/opt mounted on /opt
> rpool/output1 mounted on /output01
> etc, etc,etc
> you see them all if you look at the output here:
> http://www.wuppdich.com/combined_error.txt

Posting links to Usenet is a bad idea, that may not be there when 
someone reads the thread, keep the information here.

Your zone config was:

set zonepath=/zoneroot/localzone01
set autoboot=false
add net
set address=${mainip}/16
set physical=${interfaceprefix}0
end
add net
set address=${secondip}/$secondnetmask
${routerstring}
set physical=${secondinterface}
end
add dataset
   set name=rpool/zonedata/localzone01
end
add fs
   set dir=/output01
   set special=/output01/zone
   set type=lofs
   set options=[rw]
end

So there aren't any filesystems mounted at /home or /opt in the zone.

> (b)
> But, the local zone is behaving badly and not mounting its /opt or /
> output01
> filesystems properly. (And I think I know why. I think it's because it
> has not been
> configured to mount rpool/opt on /opt or rpool/output01 on /output01
> (ie the guy who wrote the scripts forgot that bit, and has been doing
> that bit by
> hand, I guess.) But the scripts were passed to me and I'd never run
> them before
> and someone said "hey. those new local zones don't mount /opt or /
> output01
> as separate partitions they just write that data straight to /
> (which since on the globalzone is zonepath /zoneroot/localzone01/root/
> will amount to /zoneroot/localzone01/root/output01 and
> /zoneroot/localzone01/root/opt respectively.

As I said in my reply you snipped, you have to add looback mounts to the 
zone's config.

-- 
Ian Collins

On Aug 8, 10:19=A0pm, Ian Collins <ian-n...@hotmail.com> wrote:
> Please keep context!
>
> On 08/ 9/10 09:08 AM, Paul Branon wrote:
>
> > Hi Ian,
>
> > Yes, it's a really difficult problem to spot. But, put simply, both
> > the global zone and the local zone have various partitions which act
> > as mountpoints for the zfs filesystems and they are
>
> > (a)
> > rpool/home mounted on /home
> > rpool/opt mounted on /opt
> > rpool/output1 mounted on /output01
> > etc, etc,etc
> > you see them all if you look at the output here:
> >http://www.wuppdich.com/combined_error.txt
>
> Posting links to Usenet is a bad idea, that may not be there when
> someone reads the thread, keep the information here.
>
> Your zone config was:
>
> set zonepath=3D/zoneroot/localzone01
> set autoboot=3Dfalse
> add net
> set address=3D${mainip}/16
> set physical=3D${interfaceprefix}0
> end
> add net
> set address=3D${secondip}/$secondnetmask
> ${routerstring}
> set physical=3D${secondinterface}
> end
> add dataset
> =A0 =A0set name=3Drpool/zonedata/localzone01
> end
> add fs
> =A0 =A0set dir=3D/output01
> =A0 =A0set special=3D/output01/zone
> =A0 =A0set type=3Dlofs
> =A0 =A0set options=3D[rw]
> end
>
> So there aren't any filesystems mounted at /home or /opt in the zone.
>
>
>
> > (b)
> > But, the local zone is behaving badly and not mounting its /opt or /
> > output01
> > filesystems properly. (And I think I know why. I think it's because it
> > has not been
> > configured to mount rpool/opt on /opt or rpool/output01 on /output01
> > (ie the guy who wrote the scripts forgot that bit, and has been doing
> > that bit by
> > hand, I guess.) But the scripts were passed to me and I'd never run
> > them before
> > and someone said "hey. those new local zones don't mount /opt or /
> > output01
> > as separate partitions they just write that data straight to /
> > (which since on the globalzone is zonepath /zoneroot/localzone01/root/
> > will amount to /zoneroot/localzone01/root/output01 and
> > /zoneroot/localzone01/root/opt respectively.
>
> As I said in my reply you snipped, you have to add looback mounts to the
> zone's config.
>
> --
> Ian Collins

Yes, Ian, thanks. /home is not one of the file systems that concerns
us, but /output01 definitely is and so too is /opt and yes. I
completely agree with you those mountpoints are missing in the script.
(and I think the guy has been traditionally adding the mountpoints by
hand.) I completely agree.


However, the slightly more challenging issue is one of retrieving any
wrongly written data. Because the local zones went into production
with the wrong mountpoints, (clearly.) But I'm wondering if that's
really a genuine problem at all, because we all know where the data
is. It's in the global zone under /zoneroot/localzone01/root/opt and
the same path ending in output01.

So, maybe all that needs doing is adding the loopback mounts to the
localzone and restarting it. Maybe no data needs to get physically
moved at all.

That's the issue I'm having.

Regards and many, many thanks for the sanity checking. It's mucho,
mucho appreciated.

Paulb.

On 08/ 9/10 09:30 AM, Paul Branon wrote:
> On Aug 8, 10:19 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>>
>> As I said in my reply you snipped, you have to add looback mounts to the
>> zone's config.
>
> Yes, Ian, thanks. /home is not one of the file systems that concerns
> us, but /output01 definitely is and so too is /opt and yes. I
> completely agree with you those mountpoints are missing in the script.
> (and I think the guy has been traditionally adding the mountpoints by
> hand.) I completely agree.
>
> However, the slightly more challenging issue is one of retrieving any
> wrongly written data. Because the local zones went into production
> with the wrong mountpoints, (clearly.) But I'm wondering if that's
> really a genuine problem at all, because we all know where the data
> is. It's in the global zone under /zoneroot/localzone01/root/opt and
> the same path ending in output01.

Which is probably fine.  Adding mountpoints for the sake of adding them 
is seldom a good idea.  The main reason to add a loop-back mount is to 
share data managed from the global zone to a non-global zone.  I have 
never attempted to loop-back mount read write.

> So, maybe all that needs doing is adding the loopback mounts to the
> localzone and restarting it. Maybe no data needs to get physically
> moved at all.
>
> That's the issue I'm having.

I wouldn't bother.  You know where that data is (and it's where most 
people would expect it to be).  Unless you have a compelling reason for 
complicating things' don't bother!

-- 
Ian Collins

On Aug 8, 10:54=A0pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 08/ 9/10 09:30 AM, Paul Branon wrote:
>
>
>
> > On Aug 8, 10:19 pm, Ian Collins<ian-n...@hotmail.com> =A0wrote:
>
> >> As I said in my reply you snipped, you have to add looback mounts to t=
he
> >> zone's config.
>
> > Yes, Ian, thanks. /home is not one of the file systems that concerns
> > us, but /output01 definitely is and so too is /opt and yes. I
> > completely agree with you those mountpoints are missing in the script.
> > (and I think the guy has been traditionally adding the mountpoints by
> > hand.) I completely agree.
>
> > However, the slightly more challenging issue is one of retrieving any
> > wrongly written data. Because the local zones went into production
> > with the wrong mountpoints, (clearly.) But I'm wondering if that's
> > really a genuine problem at all, because we all know where the data
> > is. It's in the global zone under /zoneroot/localzone01/root/opt and
> > the same path ending in output01.
>
> Which is probably fine. =A0Adding mountpoints for the sake of adding them
> is seldom a good idea. =A0The main reason to add a loop-back mount is to
> share data managed from the global zone to a non-global zone. =A0I have
> never attempted to loop-back mount read write.
>
> > So, maybe all that needs doing is adding the loopback mounts to the
> > localzone and restarting it. Maybe no data needs to get physically
> > moved at all.
>
> > That's the issue I'm having.
>
> I wouldn't bother. =A0You know where that data is (and it's where most
> people would expect it to be). =A0Unless you have a compelling reason for
> complicating things' don't bother!
>
> --
> Ian Collins

The compelling reason is the client said that his data was in the
wrong place because the localzone's mountpoints are not correct. And
he has been using these scripts for two years and I've only used them
once! That's why I don't know how he normally overcomes the omissions
in the scripts, because I've never seen him do it.

But part of my brief is to recover the wrongly written data and put it
where it ought to have been written. But looking at the config tells
us where the data is. It doesn't seem wrongly written at all. Wrongly
mounted, yes. Guilty as charged. But wrongly written? (I suspect not.)
But I needed to check. And that's what I'm doing.

Many thanks. I think I'm done now!

Paulb