> If one zone is paged out completely, then the other zone won't need much
> swap space, as there is plenty of free physical memory for it's pages to live
> in.
-Steve
I do not agree with that. Another zone cannot use the physical memory of the
"swapped out" zone, as there is strict hard ca
On Sat 11 Feb 2012 at 03:06PM, gerard henry wrote:
> i exactly have the same problem, but "detach; attach -u" didn't solve it
>
> But it seems that the attach -u doesn't upgrade, according to the messages:
> # zoneadm -z www attach -u
> Log File: /var/tmp/www.attach_log.LGaqKg
>Att
the problem is very hard to solve. excuse my bad english, i try to explain:
- remember that the initial OS is b151, first S11X release -> BE is
opensolaris-3
- first, i got the SRU13 iso and set a local repo with it
- i have to upgrade pkg, it creates a new BE -> opensolaris-4
- then, i upgrade to
Hi
just make sure via
pkg info entire
in global zone that it says 175 not 151, seems your global was still at
151, ie express.
Enda
On 11/02/2012 15:03, gerard henry wrote
your reply gave me an idea, but now the machine is rebooted with old BE:
- when i booted the new BE, and did attach -u, i
your reply gave me an idea, but now the machine is rebooted with old BE:
- when i booted the new BE, and did attach -u, i forgot one essential thing
explained in 13352339: ORACLE SOLARIS 11 EXPRESS 2010.11 SRU 13 REPO ISOIMAGE
- as i workoed with the lofiadm way, i forgot to re-mount it after reboo
On 11/02/2012 14:15, Enda O'Connor wrote:
Hi
According to this your global zone is at
151 ie express
Global zone version: entire@0.5.11,5.11-0.151.0.1:20101105T054056Z
in global zone run
pkg info entire
if that says 151 then can i see
pkg publisher
If pkg is set to s11 repo
and if entire is
Hi
According to this your global zone is at
151 ie express
Global zone version: entire@0.5.11,5.11-0.151.0.1:20101105T054056Z
in global zone run
pkg info entire
if that says 151 then can i see
pkg publisher
If that points to s11
can I see
pkg update -nv '*@latest'
Enda
On 11/02/2012 14:06, ger
may be attach -U
On 2/11/2012 9:06 AM, gerard henry wrote:
i exactly have the same problem, but "detach; attach -u" didn't solve it
But it seems that the attach -u doesn't upgrade, according to the
messages:
# zoneadm -z www attach -u
Log File: /var/tmp/www.attach_log.LGaqKg
A
i exactly have the same problem, but "detach; attach -u" didn't solve it
But it seems that the attach -u doesn't upgrade, according to the messages:
# zoneadm -z www attach -u
Log File: /var/tmp/www.attach_log.LGaqKg
Attach Path: /zones/www/root
Attach ZFS Dataset: rpool/zon
On 10/ 5/11 09:26 PM, casper@oracle.com wrote:
Before I go through the pain of logging a support call, has anyone
seen or fixed the following problem:
I ran an update on a fresh Solaris 11 Express system from the support
repository and after restarting, all the systems zones are dead. Th
> Before I go through the pain of logging a support call, has anyone
>seen or fixed the following problem:
>
>I ran an update on a fresh Solaris 11 Express system from the support
>repository and after restarting, all the systems zones are dead. The
>zone consoles report:
>
>SunOS Release 5.1
Are you still trouble with which site you can trust to buy
[url=http://www.gameim.com/product/RuneScape_II_gold.html]RS Gold[/url] safely,
I'll introduce one
for you, I have bought
[url=http://www.gameim.com/product/RuneScape_II_gold.html]Runescape Gold[/url]
many times from here, if you want
Are you still trouble with which site you can trust to buy
[url=http://www.gameim.com/product/RuneScape_II_gold.html]RS Gold[/url] safely,
I'll introduce one
for you, I have bought
[url=http://www.gameim.com/product/RuneScape_II_gold.html]Runescape Gold[/url]
many times from here, if you want
On 4/28/11 12:25 PM, David Tarc wrote:
What is the best practice for passing Display variables in labeled zones. I have heard about all-zones interfaces and unix domain sockets for passing the display variable. I however am finding it hard to find documentation on
Never seen this failure before.
Is it possible that you ran out of disk space?
For reference, which opensolaris build ("cat /etc/release", and "uname
-v"). Did you do any upgrading? If so, from which prior build?
It seems that you've lost your /etc/zones/index file. Perhaps there is
a ba
Back to the original question (locked-shm-memory on servers):
If you are running multiple applications on a server, and at least one
of them uses shared memory, you should consider using max-shm-memory
or max-locked-memory for the zone that will use shared memory.
Any memory that a process locks
Hi
Locked memory is typically used by oracle database, ie ISM/DISM segments
etc, not likely to be used on desktop, apps that use shared memory tend
to try and pin it in memory to give max performance.
I wouldn't think a desktop would need this typically.
De
On 29/11/2010 19:16, Jordan Vaughan
"Locked memory" is the same as "pinned memory": In other words, pages
that won't be paged to disk. Applications can request that pages be
"locked" into memory. The pager won't page locked pages to disk.
Regarding an "appropriate value for desktop usage": It depends on what
kinds of applicati
At the same time, I would like to ask exactly what is "locked" RAM? How much is
an apropriate value for desktop usage? 2GB?
add capped-memory
set locked=2GB
end
--
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@
On 11/ 3/10 02:21 PM, Henrik Johansson wrote:
On Nov 3, 2010, at 1:22 AM, Ian Collins wrote:
On Nov 3, 2010, at 12:06 AM, Ian Collins wrote:
On 11/ 3/10 11:56 AM, Henrik Johansson wrote:
I would ideally like to do two things:
1. Have all filesystem configuration for the zone in the pool as
we
On Nov 3, 2010, at 1:22 AM, Ian Collins wrote:
>>
>> On Nov 3, 2010, at 12:06 AM, Ian Collins wrote:
>>
>>> On 11/ 3/10 11:56 AM, Henrik Johansson wrote:
I would ideally like to do two things:
1. Have all filesystem configuration for the zone in the pool as we have
wi
On 11/ 3/10 12:56 PM, Henrik Johansson wrote:
Hello Ian,
Thanks four your answer, more below.
On Nov 3, 2010, at 12:06 AM, Ian Collins wrote:
On 11/ 3/10 11:56 AM, Henrik Johansson wrote:
I would ideally like to do two things:
1. Have all filesystem configuration for the zone in the pool
Hello Ian,
Thanks four your answer, more below.
On Nov 3, 2010, at 12:06 AM, Ian Collins wrote:
> On 11/ 3/10 11:56 AM, Henrik Johansson wrote:
>>
>>
>> I would ideally like to do two things:
>>
>> 1. Have all filesystem configuration for the zone in the pool as we have
>> with the global z
On 11/ 3/10 11:56 AM, Henrik Johansson wrote:
Hi all,
I would like you take on this for a large zone installation.
I am going to create zones on zpools with a pool for the zoneroot and
another pool for for application data, the second pool can differ in
layout, disk system and properties and
On 08/ 6/10 01:43 AM, Prasoon Bansal wrote:
Hello Benr,
I had read all the reply of your query posted on this blog.
Which blog? Your post appears to be an orphan.
I have the same matching query with the others. As i had configured the
non-global zone on nfs shared folder(nfsserver) and thi
Hello Benr,
I had read all the reply of your query posted on this blog. I have the same
matching query with the others. As i had configured the non-global zone on nfs
shared folder(nfsserver) and this shared folder is mapped onto another
host(testzone). I am able to configured and see the statu
On Wed, 2010-03-31 at 18:01 -0700, Brett wrote:
> Hi Folks,
>
> I would like to source opinions of the forum on whether its better to share a
> zfs storage pool for all zones on a machine or create one zpool per zone? The
> premise is that this zpool (zonepool) would be sitting on san storage.
>
Brett wrote:
Hi Folks,
I would like to source opinions of the forum on whether its better to share a
zfs storage pool for all zones on a machine or create one zpool per zone? The
premise is that this zpool (zonepool) would be sitting on san storage.
I posed that a consolidated pool (zonepool)
update on this one:
a workaround if you so will, or the more appropriate way to do this is
apparently
to use lofiadm(1M) to create a pseudo block device comprising the file hosted
on NFS
and use the created lofi device (eg. /dev/lofi/1) as the device for zpool create
and all subsequent I/O (thi
On Fri, Jan 22, 2010 at 11:42 AM, Frank Batschulat (Home) <
frank.batschu...@sun.com> wrote:
> On Fri, 22 Jan 2010 18:30:39 +0100, Gael wrote:
>
> >> This is bug:
> >>
> >> 6857294 zoneadm attach leads to partially installed packages
> >>
> >> I believe a T patch might be available for the S10 SV
On Fri, 22 Jan 2010 18:30:39 +0100, Gael wrote:
>> This is bug:
>>
>> 6857294 zoneadm attach leads to partially installed packages
>>
>> I believe a T patch might be available for the S10 SVr4 packaging code
>> if you need it, but I see that the fix has not yet been integrated
>> into the nv SVr4
On Tue, Sep 15, 2009 at 1:02 PM, Jerry Jelinek wrote:
> Gael wrote:
>
>> Hello
>>
>> I have been experimenting a few ways to speed up patching a bunch of
>> machines running whole zones (parallel patching, zoneadm attach -u).
>> I have encountered one issue with the attach -u way... Before initia
On Tue, Jan 19, 2010 at 02:33:15PM -0700, Jerry Jelinek wrote:
> On 01/19/10 14:00, Edward Pilatowicz wrote:
> >>> perhaps it would make sense to add some "tokens" to the comments in
> >>> brand_asm.h like:
> >>> 32-BIT INTERPOSITION STACK
> >>> 32-BIT LCALL/INT STACK
> >>> 64-BIT INTERPO
On 01/19/10 14:00, Edward Pilatowicz wrote:
perhaps it would make sense to add some "tokens" to the comments in
brand_asm.h like:
32-BIT INTERPOSITION STACK
32-BIT LCALL/INT STACK
64-BIT INTERPOSITION STACK
64-BIT LCALL/INT STACK
and then in the comments
On Mon, Jan 18, 2010 at 12:51:27PM -0700, Jerry Jelinek wrote:
> Ed,
>
> Thanks for reviewing this, my responses are inline.
>
> On 01/15/10 19:26, Edward Pilatowicz wrote:
> >On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote:
> >>I need a code review for my proposed fix for:
> >>
> >>6
Ed,
Thanks for reviewing this, my responses are inline.
On 01/15/10 19:26, Edward Pilatowicz wrote:
On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote:
I need a code review for my proposed fix for:
6887823 brandz on x86 should ignore %gs and simplify brand hooks
There is a webrev
On Thu, Jan 14, 2010 at 09:18:20AM -0700, Jerry Jelinek wrote:
> I need a code review for my proposed fix for:
>
> 6887823 brandz on x86 should ignore %gs and simplify brand hooks
>
> There is a webrev at:
>
> http://cr.opensolaris.org/~gjelinek/webrev.6887823/
>
> This simplifies some of the handl
On 01/14/10 08:18 AM, Jerry Jelinek wrote:
I need a code review for my proposed fix for:
6887823 brandz on x86 should ignore %gs and simplify brand hooks
There is a webrev at:
http://cr.opensolaris.org/~gjelinek/webrev.6887823/
This simplifies some of the handling for the %gs register, cleans
On Fri, 08 Jan 2010 18:33:06 +0100, Mike Gerdts wrote:
> I've written a dtrace script to get the checksums on Solaris 10.
> Here's what I see with NFSv3 on Solaris 10.
jfyi, I've reproduces it as well using a Solaris 10 Update 8 SB2000 sparc client
and NFSv4.
much like you I also get READ error
On Fri, Jan 8, 2010 at 9:11 AM, Mike Gerdts wrote:
> I've seen similar errors on Solaris 10 in the primary domain and on a
> M4000. Unfortunately Solaris 10 doesn't show the checksums in the
> ereport. There I noticed a mixture between read errors and checksum
> errors - and lots more of them.
On Fri, Jan 8, 2010 at 5:28 AM, Frank Batschulat (Home)
wrote:
[snip]
> Hey Mike, you're not the only victim of these strange CHKSUM errors, I hit
> the same during my slightely different testing, where I'm NFS mounting an
> entire, pre-existing remote file living in the zpool on the NFS server an
Mike Gerdts wrote:
> This unsupported feature is supported with the use of Sun Ops Center
> 2.5 when a zone is put on a "NAS Storage Library".
Ah, ok. I didn't know that.
--
James Carlson 42.703N 71.076W
___
zones-discuss mailing list
On Fri, Jan 8, 2010 at 6:51 AM, James Carlson wrote:
> Frank Batschulat (Home) wrote:
>> This just can't be an accident, there must be some coincidence and thus
>> there's a good chance
>> that these CHKSUM errors must have a common source, either in ZFS or in NFS ?
>
> One possible cause would b
Frank Batschulat (Home) wrote:
> This just can't be an accident, there must be some coincidence and thus
> there's a good chance
> that these CHKSUM errors must have a common source, either in ZFS or in NFS ?
One possible cause would be a lack of substantial exercise. The man
page says:
On Wed, 23 Dec 2009 03:02:47 +0100, Mike Gerdts wrote:
> I've been playing around with zones on NFS a bit and have run into
> what looks to be a pretty bad snag - ZFS keeps seeing read and/or
> checksum errors. This exists with S10u8 and OpenSolaris dev build
> snv_129. This is likely a blocker
On Tue, Dec 22, 2009 at 9:34 PM, Mike Gerdts wrote:
> On Tue, Dec 22, 2009 at 8:02 PM, Mike Gerdts wrote:
>> I've been playing around with zones on NFS a bit and have run into
>> what looks to be a pretty bad snag - ZFS keeps seeing read and/or
>> checksum errors. This exists with S10u8 and Open
On Tue, Dec 22, 2009 at 8:02 PM, Mike Gerdts wrote:
> I've been playing around with zones on NFS a bit and have run into
> what looks to be a pretty bad snag - ZFS keeps seeing read and/or
> checksum errors. This exists with S10u8 and OpenSolaris dev build
> snv_129. This is likely a blocker for
Edward Pilatowicz wrote:
so we're actually changing our stack pointer after entry into the
kernel, so it's no longer necessarily matching the interrupt stack that
the processor switched in automatically and saved the parameters on.
notably we don't do this for 32-bit kernels. this means that
de-
On Fri, Dec 18, 2009 at 08:19:02AM -0700, Jerry Jelinek wrote:
> Jerry Jelinek wrote:
> >Because its not right above, all of the other register values are
> >also pushed on the stack, so we need to go through the SSP to get
> >to the right spot. I can add a comment explaining this but the
> >32bit
Jerry Jelinek wrote:
Because its not right above, all of the other register values are
also pushed on the stack, so we need to go through the SSP to get
to the right spot. I can add a comment explaining this but the
32bit and 64bit stacks are not identical.
Ed,
Actually, what I said above is
Edward Pilatowicz wrote:
so now you have:
---8<---
#define V_U_EIP (CLONGSIZE * 0)
...
GET_V(%rsp, 1, V_SSP, %rax) /* get saved stack pointer */
SET_V(%rax, 0, V_U_EIP, %r15) /* save new return addr in %eip */
---8<---
but why can't this be identical to the 32-bit p
On Thu, Dec 17, 2009 at 04:24:22PM -0700, Jerry Jelinek wrote:
> Edward Pilatowicz wrote:
> >to be:
> >---8<---
> >/*
> > * The saved stack pointer (V_SSP) points to the interrupt specific
> > * state, which is saved directly above the stack contents common to all
> > * callbacks.
> >...
> >*/
> >#
Edward Pilatowicz wrote:
On Thu, Dec 17, 2009 at 09:39:34AM -0700, Jerry Jelinek wrote:
Edward Pilatowicz wrote:
- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64
versions, it assumes the syscall number is in eax/rax, and it has a
side effect of munging the syscall number.) ho
On Thu, Dec 17, 2009 at 09:39:34AM -0700, Jerry Jelinek wrote:
> Edward Pilatowicz wrote:
> >- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64
> > versions, it assumes the syscall number is in eax/rax, and it has a
> > side effect of munging the syscall number.) how about defining
Edward Pilatowicz wrote:
- CALC_TABLE_ADDR() a little clunky. (it has seperate 32 and 64
versions, it assumes the syscall number is in eax/rax, and it has a
side effect of munging the syscall number.) how about defining just one
version of CALC_TABLE_ADDR() as:
---8<---
#define CALC_TABLE
On Wed, Dec 16, 2009 at 02:37:36PM -0700, Jerry Jelinek wrote:
> Ed,
>
> Edward Pilatowicz wrote:
> >On Wed, Dec 16, 2009 at 10:46:57AM -0700, Jerry Jelinek wrote:
> >>Ed,
> >>
> >>I've posted an updated webrev to address your comments.
> >>
> >>http://cr.opensolaris.org/~gjelinek/webrev.6768950/
>
Ed,
Edward Pilatowicz wrote:
On Wed, Dec 16, 2009 at 10:46:57AM -0700, Jerry Jelinek wrote:
Ed,
I've posted an updated webrev to address your comments.
http://cr.opensolaris.org/~gjelinek/webrev.6768950/
usr/src/uts/intel/brand/sn1/sn1_brand_asm.s
- i'd think the "is 0 <= syscall <= MAX"
On Wed, Dec 16, 2009 at 10:46:57AM -0700, Jerry Jelinek wrote:
> Ed,
>
> I've posted an updated webrev to address your comments.
>
> http://cr.opensolaris.org/~gjelinek/webrev.6768950/
>
usr/src/uts/intel/brand/sn1/sn1_brand_asm.s
- i'd think the "is 0 <= syscall <= MAX" check would have to be
Ed,
I've posted an updated webrev to address your comments.
http://cr.opensolaris.org/~gjelinek/webrev.6768950/
Let me know if you have any other comments or see anything
with the changes I made.
Thanks,
Jerry
___
zones-discuss mailing list
zones-dis
Jordan Vaughan wrote:
--
usr/src/lib/brand/sn1/sn1_brand/amd64/sn1_handler.s
44: Shouldn't this function be named "sn1_handler_table"?
Jordan,
Good catch, I'll fix that.
Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris
On 12/15/09 07:39 AM, Jerry Jelinek wrote:
I have an initial code review for the fix for bug:
6768950 panic[cpu1]/thread=ff084ce0b3e0: syscall_asm_amd64.s:480
lwp ff0756a8cdc0, pcb_rupdate != 0
There is a webrev at:
http://cr.opensolaris.org/~gjelinek/webrev.6768950/
The code
On Tue, Dec 15, 2009 at 01:28:01PM -0700, Jerry Jelinek wrote:
> Ed,
>
> Thanks for reviewing this. My responses to your comments are
> in-line.
>
> Edward Pilatowicz wrote:
> >On Tue, Dec 15, 2009 at 08:39:12AM -0700, Jerry Jelinek wrote:
> >>I have an initial code review for the fix for bug:
> >
Ed,
Thanks for reviewing this. My responses to your comments are
in-line.
Edward Pilatowicz wrote:
On Tue, Dec 15, 2009 at 08:39:12AM -0700, Jerry Jelinek wrote:
I have an initial code review for the fix for bug:
6768950 panic[cpu1]/thread=ff084ce0b3e0: syscall_asm_amd64.s:480
lw
On Tue, Dec 15, 2009 at 08:39:12AM -0700, Jerry Jelinek wrote:
> I have an initial code review for the fix for bug:
>
> 6768950 panic[cpu1]/thread=ff084ce0b3e0: syscall_asm_amd64.s:480
> lwp ff0756a8cdc0, pcb_rupdate != 0
>
> There is a webrev at:
>
> http://cr.opensolaris.org/~gjel
On Fri, Nov 27, 2009 at 02:47:37PM -0800, Frank Batschulat wrote:
> Hey Ed, addition to my previous posting as I just noticed something I've
> totally
> forgotten about
>
> > afaik, determining the mount point should be pretty
> > strait forward. i was planning to get a list of all the shares
On Fri, Nov 27, 2009 at 09:12:33AM -0800, Frank Batschulat wrote:
> Hey Ed, I want to comment on the NFS aspects involed here,
>
> On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz wrote:
> >
> >well, it all depends on what nfs shares are actually being exported.
>
> I definitively think we do wan
Hey Ed, addition to my previous posting as I just noticed something I've totally
forgotten about
> afaik, determining the mount point should be pretty
> strait forward. i was planning to get a list of all the shares
> exported by the specified nfs server, and then do a strncmp() of all the
> e
Hey Ed, I want to comment on the NFS aspects involed here,
On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz wrote:
>
>well, it all depends on what nfs shares are actually being exported.
I definitively think we do want to abstain from that much programmatic
attempts inside the Zones framework
Alex George wrote:
Hi
I would like to know more abt zones, How zones work, what are types of zones
,what is the best method to install zones.
Is zones and containers are both same.
Pls need help on above topic
The docs in this page should help.
http://opensolaris.org/os/community/zones/
On Mon, Sep 21, 2009 at 10:23:21AM -0700, Edward Pilatowicz wrote:
> if we only support vdisks created via vdiskadm(1m), then we'll always
> have a directory and we can always use vdiskadm(1m) to sniff out if it's
> a valid vdisk and access it as such.
>
> then for the implicit creation case we'l
On Mon, Sep 21, 2009 at 04:25:30PM +0100, John Levon wrote:
> On Wed, Sep 16, 2009 at 09:33:11PM -0700, Edward Pilatowicz wrote:
>
> > there by implying that the vdisk path is a directory. ok. that's easy
>
> Right.
>
> > enough to detect.
>
> It's probably safer to directly use vdiskadm to sniff
On Wed, Sep 16, 2009 at 09:33:11PM -0700, Edward Pilatowicz wrote:
> there by implying that the vdisk path is a directory. ok. that's easy
Right.
> enough to detect.
It's probably safer to directly use vdiskadm to sniff the directory, if
you can.
> > At import time, it's a combination of sni
On Thu, Sep 17, 2009 at 01:13:53AM +0100, John Levon wrote:
> On Wed, Sep 16, 2009 at 04:34:06PM -0700, Edward Pilatowicz wrote:
>
> > thanks for taking the time to look at this and sorry for the delay in
> > replying.
>
> Compared to /my/ delay...
>
> > > That is, I think vdisks should just use pa
hey illya,
thanks for reviewing this and sorry for the delay in replying.
my comments are inline below.
i've also attached a document that contains some of the design doc
sections i've revised based of your (and john's) feedback. since the
document is large, i've only included sections that i've
On Wed, Sep 16, 2009 at 04:34:06PM -0700, Edward Pilatowicz wrote:
> thanks for taking the time to look at this and sorry for the delay in
> replying.
Compared to /my/ delay...
> > That is, I think vdisks should just use path:/// and nfs:// not have
> > their own special schemes.
>
> this is ea
thanks for taking the time to look at this and sorry for the delay in
replying. my comments are line below.
ed
On Sat, Sep 05, 2009 at 11:13:07PM +0100, John Levon wrote:
> On Thu, May 21, 2009 at 04:55:15PM +0800, Edward Pilatowicz wrote:
>
> > File storage objects:
> >
> > path:///
> >
On Tue, Sep 15, 2009 at 2:02 PM, Jerry Jelinek wrote:
> Gael wrote:
>>
>> Hello
>>
>> I have been experimenting a few ways to speed up patching a bunch of
>> machines running whole zones (parallel patching, zoneadm attach -u).
>> I have encountered one issue with the attach -u way... Before initia
Gael wrote:
Hello
I have been experimenting a few ways to speed up patching a bunch of
machines running whole zones (parallel patching, zoneadm attach -u).
I have encountered one issue with the attach -u way... Before initiating a
case with sun, I was wondering if it was a well known issue...
T
Hi Edward,
See comments and questions below inline:
1. Section C.0
> ... That said, nothing in this proposal should not prevent us from adding
> support for...
That "not" before "prevent" is superfluous.
2. Section C.1.i
How many instances of "rootzpool" and "zpool" resources is permitted?
IMO
On Thu, May 21, 2009 at 04:55:15PM +0800, Edward Pilatowicz wrote:
> File storage objects:
>
> path:///
> nfs://[:port]/
>
> Vdisk storage objects:
>
> vpath:///
> vnfs://[:port]/
This makes me uncomfortable. The fact it's a vdisk is derivable except
in one case: creation. And
On Sat, Sep 05, 2009 at 09:02:34AM +0300, Illya Kysil wrote:
> Hi Edward,
>
> On Sat, Sep 5, 2009 at 03:03, Edward
> Pilatowicz wrote:
> > i posted the latest version to our aliases in may after i incorporated
> > mike's feedback, but digging throught the archives i couldn't find any
> > decent rea
Hi Edward,
On Sat, Sep 5, 2009 at 03:03, Edward
Pilatowicz wrote:
> i posted the latest version to our aliases in may after i incorporated
> mike's feedback, but digging throught the archives i couldn't find any
> decent readable copy. hence i've gone ahead and posted the latest
> version to zone
hey illya,
i posted the latest version to our aliases in may after i incorporated
mike's feedback, but digging throught the archives i couldn't find any
decent readable copy. hence i've gone ahead and posted the latest
version to zones community site here:
http://www.opensolaris.org/os/community
comments inline below.
ed
On Fri, May 22, 2009 at 11:26:06AM -0500, Mike Gerdts wrote:
> On Fri, May 22, 2009 at 1:57 AM, Edward Pilatowicz
> wrote:
> >
> > i've attached an updated version of the proposal (v1.1) which addresses
> > your feedback. (i've also attached a second copy of the new pro
On Fri, May 22, 2009 at 1:57 AM, Edward Pilatowicz
wrote:
> hey mike,
>
> thanks for all the great feedback.
> my replies to your individual comments are inline below.
Thanks. I've responded inline where needed.
>
> i've attached an updated version of the proposal (v1.1) which addresses
> your
[ third reply, includes revised proposal + change bars from previous
version ]
hey mike,
thanks for all the great feedback.
my replies to your individual comments are inline below.
i've updated my proposal to include your feedback, but i'm unable to
attach it to this reply because of mail size
[ second reply, includes revised proposal ]
hey mike,
thanks for all the great feedback.
my replies to your individual comments are inline below.
i've updated my proposal to include your feedback, but i'm unable to
attach it to this reply because of mail size restrictions imposed by
this alias.
hey mike,
thanks for all the great feedback.
my replies to your individual comments are inline below.
i've updated my proposal to include your feedback, but i'm unable to
attach it to this reply because of mail size restrictions imposed by
this alias. i'll send some follow up emails which includ
On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz
wrote:
> hey all,
>
> i've created a proposal for my vision of how zones hosted on shared
> storage should work. if anyone is interested in this functionality then
> please give my proposal a read and let me know what you think. (fyi,
> i'm leav
solarg wrote:
thanks for all reply, but can you suggest a way to lower the space
occupied by a such zone? the problem with os2008.11 is that everything
is installed at initial setup, but having zones occupying more than 5Gb
is very bad!
This is incorrect. Only a small subset of packages are
thanks for all reply, but can you suggest a way to lower the space
occupied by a such zone? the problem with os2008.11 is that everything
is installed at initial setup, but having zones occupying more than 5Gb
is very bad!
gerard
___
zones-discuss m
On Thu, Apr 30, 2009 at 09:33:57AM -0600, Jerry Jelinek wrote:
> solarg wrote:
>> hello all,
>> i'm wondering how to create a sparse zone in os2008.11:
>
> Sparse zones are not currently supported on opensolaris.
>
> This is tracked as:
> 2550 Support for sparse root zones
>
>> - in solaris 10, jus
On Thu, Apr 30, 2009 at 11:25 AM, solarg wrote:
> hello all,
> i'm wondering how to create a sparse zone in os2008.11:
> - in solaris 10, just use "create" instead of "create -b" does a "sparse"
> zone
> - in os2008.11, you have to add manually:
> add inherit-pkg-dir
Ermmm ... I don't think zones
solarg wrote:
hello all,
i'm wondering how to create a sparse zone in os2008.11:
Sparse zones are not currently supported on opensolaris.
This is tracked as:
2550 Support for sparse root zones
- in solaris 10, just use "create" instead of "create -b" does a
"sparse" zone
- in os2008.11, you
Le 6 avr. 09 à 21:12, Paul Davis a écrit :
121430-33 (or higher) supports ZFS root with ZFS zonepaths (each in
their own zpools). Been testing this extensively as a POC and it
works, lucreate plus patching.
This is a really GOOD NEWS !I just want to sing or dance, or
anything like
On Mon, Apr 6, 2009 at 3:12 PM, Paul Davis wrote:
>
> 121430-33 (or higher) supports ZFS root with ZFS zonepaths (each in their
> own zpools). Been testing this extensively as a POC and it works, lucreate
> plus patching. We did file bug 6819838 on preservation of mountpoint
> settings after lucre
121430-33 (or higher) supports ZFS root with ZFS zonepaths (each in
their own zpools). Been testing this extensively as a POC and it works,
lucreate plus patching. We did file bug 6819838 on preservation of
mountpoint settings after lucreate when set at the zfs level vs. zpool
level, but othe
Hello.
On Mon, Apr 6, 2009 at 13:46, Nicolas Dorfsman wrote:
>
>
>Hi all,
>
>
>I'm waiting for some patch to allow non-local zones to be located
> out of the rpool before upgrading my customer mainframe
> (s/mainframe/sf15k/).
>
>Is there anybody here who knows if or when
Hi
As far as I'm aware the latest Lu patches remove this restriction
121430-xx, but I have cc'ed the zfs team for some guidance.
Enda
Alexander Skwar wrote:
Hi!
On Mon, Apr 6, 2009 at 19:55, Nicolas Dorfsman wrote:
Le 6 avr. 09 à 19:35, Alexander Skwar a écrit :
On Mon, Apr 6
Hi!
On Mon, Apr 6, 2009 at 19:55, Nicolas Dorfsman wrote:
>
> Le 6 avr. 09 à 19:35, Alexander Skwar a écrit :
>
>> On Mon, Apr 6, 2009 at 13:46, Nicolas Dorfsman
>> wrote:
>>
>>>
>>> I'm waiting for some patch to allow non-local zones to be located
>>> out of the rpool before upgrading my
1 - 100 of 290 matches
Mail list logo
