Re: [zones-discuss] Can we create RAID 0 + 1 while doing jumpstart
Hello Sanjay, Wednesday, October 1, 2008, 3:11:12 PM, you wrote: Hi All, Can we create RAID 0 + 1 Volume(mirror) while doing jumpstart? need help on this yes, you can. Do something like: filesysmirror:d0 c0t0d0s1 c0t1d0s1 8192 / filesysmirror:d5 c0t0d0s3 c0t1d0s3 8192 /var filesysmirror:d15 c0t0d0s0 c0t1d0s0 8192 swap metadbc0t0d0s7 size 8192 count 3 metadb c0t1d0s7 size 8192 count 3 -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip zones with defrouter
On 10/06/08 21:38, Glenn Faden wrote: Max, The default route option is not specific to TX zones. However, it is intended for environments where your zones aren't sharing the same physical interfaces. This feature sets the default route for an interface so I don't think it will provide the functionality you are looking for. --Glenn Hi Glenn, The preliminary documents say the same thing, that the 'defrouter' is for the interface. I see an opportunity to clarify the behavior as my initial expectation was that since the defrouter attribute is set in a zone's configuration, it applies to the zone. What happens when multiple zone configurations have different defrouter definitions for the same interface or the same subnet (given the complexity should multiple subnets be configured on a single interface)? Thanks Steffen Max Levine wrote: Hi, We have a need to define a separate defaultroute for some of the shared-ip zones in our environment. All of the zones are on the same subnet, but only some need to have a different default route. I was reading psarc/2008/057 but I am confused if the functionality applies to zones on same subnet? Also I saw that this functionality was backported to Solaris 10 zoneadm patch, but it mentiones TX zones. Does this only apply to TX or regular zones as well? ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] backup/restore within a non-global zone of lofs data
Hello Steffen, Monday, October 6, 2008, 10:27:26 PM, you wrote: SW Hi, SW http://docs.sun.com/app/docs/doc/817-1592/gbbxq?a=view has a caution SW regarding restoring a lofs mounted filesystem within a non-global zone. SW The prior paragraph makes reference to system read-only mount points. SW With the exception of possible access from other zones (the global, or SW shared access non-global zones), I don't see a reason why a non-system SW lofs directory could not be backed up and restored from within a SW non-global zone. Am I missing something? I guess the doc is referring to sparse root zones mostly when lofs filesystems are mounted RO so you won't be able to restore them within a zone anyway. Then you would backup same data many times when having multiple zones. Another issue could be that you coul dendup restoring /usr /lib etc. in global zone which might render your system unusable. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Shared-ip zones with defrouter
Steffen, The defrouter feature doesn't change any existing kernel functionality. It simply automates setting up routes which could have been established by the global zone administrator. Whether those routes are useful depends on factors beyond the zone configuration. --Glenn Steffen Weiberle wrote: On 10/06/08 21:38, Glenn Faden wrote: Max, The default route option is not specific to TX zones. However, it is intended for environments where your zones aren't sharing the same physical interfaces. This feature sets the default route for an interface so I don't think it will provide the functionality you are looking for. --Glenn Hi Glenn, The preliminary documents say the same thing, that the 'defrouter' is for the interface. I see an opportunity to clarify the behavior as my initial expectation was that since the defrouter attribute is set in a zone's configuration, it applies to the zone. What happens when multiple zone configurations have different defrouter definitions for the same interface or the same subnet (given the complexity should multiple subnets be configured on a single interface)? Thanks Steffen Max Levine wrote: Hi, We have a need to define a separate defaultroute for some of the shared-ip zones in our environment. All of the zones are on the same subnet, but only some need to have a different default route. I was reading psarc/2008/057 but I am confused if the functionality applies to zones on same subnet? Also I saw that this functionality was backported to Solaris 10 zoneadm patch, but it mentiones TX zones. Does this only apply to TX or regular zones as well? ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code review for zones support in SNAP
Comments, mostly on libbe ...
General comment - Since we don't yet support boot environments
within a zone, beadm should fail gracefully when run in a zone, like:
# beadm subcommand
beadm is not supported in a zone.
rather then trying to do something and failing miserably. Most of
the if(GLOBAL_ZONEID) checks we have in libbe now are really
just primers for when we build in that support.
usr/src/man/beadm.1m.txt
--
333 - SUNWinstall - SUNWbeadm
messages.py
126 - BE_ERR_NO_ACTIVE_ROOT should be in here.
be_activate.c
-
136 - initialize to { 0 }
169-199 - This whole chunk needs to be encapsulated inside a
if (GLOBAL) {
}
215-221, 241-245 - These two chunks seem like they could be
moved up into the if (GLOBAL) {} from 169.
With some refactoring, the zfs_promote() calls in set_canmount()
could probably be ripped out and replaced by calls to be_promote_zone_ds()
(renamed to something more generic like be_promote_ds() of course).
I never understood why the zfs_promote() calls were hidden in the
set_canmount() function anyway. If we don't get to this per the code
review changes, please file a bug to track this.
972-1023 - This whole chunk can be removed if you replace 1025-1026
with a direct call to the callback giving it the root dataset of the
zone BE.
i.e. replace 1025-1026 with:
if (be_promote_sub_ds_callback(z_zhp, NULL) != 0) {
1028 - remove subordinate
Rename the following functions to be more generic:
be_promote_zone_ds() -- be_promote_ds()
be_promote_sub_ds_callback() -- be_promote_ds_callback()
be_create.c:
---
1880 - future
1878-1883 - this comment needs to be removed. It doesn't apply to
this section of code.
1884 - within the context of this function - that is, code running in the
global zone that's processing non-global zones - this if() can be removed,
along with 1895.
1944 - A comment stating this is getting the uuid of the newly cloned
parent BE would be nice.
2772-2774 - Missing function block comment.
libbe.h:
-
117 - not - no
177 - Remove this line; its not used anywhere.
thanks,
-ethan
Evan Layton wrote:
Hello All,
We're down to the wire on the zone support changes to SNAP upgrade and are
looking for code review comments. We'll be taking comments up until COB
Tuesday
October 7th. Your comments are as always welcome and appreciated.
Defect 3686 is the blocker bug that was submitted to cover this work and the
webrev is available at:
http://cr.opensolaris.org/~equach/webrev.snap_zones/
Thank you in advance for your comments and help!
-evan
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] Code review for zones support in SNAP
be_activate.c: I agree with Joe that the getzoneid() == GLOBAL_ZONEID checks should be in the functions if possible. Makes for cleaner code. 884,893,947: some variables use uppercase notation e.g. (zoneDataset zoneIndex zonePath) and some don't. Please be consistent throughout. NIT: 890: zones - zone_list seems more appropriate. 911: zoneDataset is being used before being set. It could be NULL here. 954: To help with indentation and code maintenance, this line could be split up and if each condition isn't true then continue. This will help subsequent lines from being wrapped so much. 994: This while loop seems like a good candidate for a new function, adding to code maintainability. Looks like 1096 shares this code making it an even better candidate for a function. :-) 1072: Can zhp ever be NULL? If so this line should be split up since there is no error condition for when it is NULL. I'll review be_mount.c next and send comments in a separate mail. Thanks Tim Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] Code review for zones support in SNAP
be_mount.c: 53: Why not add this struct to libbe_priv.h where the other structs live? Nit: 294, 2208: The comment should spell out variable names (altroot) for clarity sake. 333: Mounted - Mount 529: mflag can go away. Just pass 0 on 552. 546: failed to - failed to mount a 547: dataset mountpoint - dataset. Mountpoint 575: boolean_t seems a better choice since this function only has 2 states to return. Also calls to this function then don't have to compare against an int. 592: zone - zone root Nit: 628,629 Add periods 625-629 Consistent capitalization 679 get - an extra get 702: Spell out altroot in comment; alternate root 644,715,750... zone_mounted_here the here is ambiguous, suggest just zone_mounted 846: The - This 1409,1450: err isn't needed. Just call strerror(errno) on 1453 1412: if zoned is meant to be a delegated zone then it should be spelled out here. 1447: for - typo 1922: the where - to where 2151, 2221: strcat() - strlcat() Thanks Tim Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss Evan, I will review this today, Monday October 6. Joe ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code review for zones support in SNAP
Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ zones-discuss mailing list zones-discuss@opensolaris.org usr/src/lib/libbe/be_create.c: line 1306 - the goto isn't needed line 1381 - We're not collecting any errors that may have been returned from be_get_snap and just returning a generic BE_ERR_ZFS be_errno. Can we collect any useful information from errors returned by this call? line 1420 - We're not capturing any errors here and just returning whatever ret was set to previously, which in this case appears to be 0. line 1519 - We should be collecting the error returned from _be_mount instead of returning the generic mount error. line 1539 - same as 1519 but for unmount. line 1635 - Why not just goto done instead of the ZFS_CLOSE and return? unless the callback function has already closed the zfs handle. line 1638 - shouldn't the callback function be_destroy_zone_roots_callback have already closed the zfs handle? line 1705 - shouldn't this callback function always close the zfs handle? line 1719 - if the comparison fails we don't close the zfs handle here. line 2772 - We need a comment header for this function. moving on to be_mount.c -evan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code review for zones support in SNAP
Ethan Quach wrote:
Comments, mostly on libbe ...
General comment - Since we don't yet support boot environments
within a zone, beadm should fail gracefully when run in a zone, like:
# beadm subcommand
beadm is not supported in a zone.
rather then trying to do something and failing miserably. Most of
the if(GLOBAL_ZONEID) checks we have in libbe now are really
just primers for when we build in that support.
usr/src/man/beadm.1m.txt
--
333 - SUNWinstall - SUNWbeadm
messages.py
126 - BE_ERR_NO_ACTIVE_ROOT should be in here.
be_activate.c
-
136 - initialize to { 0 }
fixed
169-199 - This whole chunk needs to be encapsulated inside a
if (GLOBAL) {
}
moved
215-221, 241-245 - These two chunks seem like they could be
moved up into the if (GLOBAL) {} from 169.
moved
With some refactoring, the zfs_promote() calls in set_canmount()
could probably be ripped out and replaced by calls to be_promote_zone_ds()
(renamed to something more generic like be_promote_ds() of course).
I never understood why the zfs_promote() calls were hidden in the
set_canmount() function anyway. If we don't get to this per the code
review changes, please file a bug to track this.
refactored this so that the promote's are now done with calls to
be_promote_ds_callback and are no longer in set_callback (where they never
really should have been in the first place...).
972-1023 - This whole chunk can be removed if you replace 1025-1026
with a direct call to the callback giving it the root dataset of the
zone BE.
i.e. replace 1025-1026 with:
if (be_promote_sub_ds_callback(z_zhp, NULL) != 0) {
done
1028 - remove subordinate
Rename the following functions to be more generic:
be_promote_zone_ds() -- be_promote_ds()
be_promote_sub_ds_callback() -- be_promote_ds_callback()
I renamed be_promote_sub_ds_callback() to be_promote_ds_callback() However I
left be_promote_zone_ds() as is since it's doing a bunch of zones lookup to
find
the zones and the correct zones datasets to promote before calling
be_promote_ds_callback().
be_create.c:
---
1880 - future
fixed
1878-1883 - this comment needs to be removed. It doesn't apply to
this section of code.
fixed
1884 - within the context of this function - that is, code running in the
global zone that's processing non-global zones - this if() can be removed,
along with 1895.
I removed them.
1944 - A comment stating this is getting the uuid of the newly cloned
parent BE would be nice.
comment added
2772-2774 - Missing function block comment.
libbe.h:
-
117 - not - no
177 - Remove this line; its not used anywhere.
thanks,
-ethan
Evan Layton wrote:
Hello All,
We're down to the wire on the zone support changes to SNAP upgrade and
are looking for code review comments. We'll be taking comments up
until COB Tuesday October 7th. Your comments are as always welcome and
appreciated.
Defect 3686 is the blocker bug that was submitted to cover this work
and the webrev is available at:
http://cr.opensolaris.org/~equach/webrev.snap_zones/
Thank you in advance for your comments and help!
-evan
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] Code review for zones support in SNAP
Tim Knitter wrote: be_activate.c: I agree with Joe that the getzoneid() == GLOBAL_ZONEID checks should be in the functions if possible. Makes for cleaner code. 884,893,947: some variables use uppercase notation e.g. (zoneDataset zoneIndex zonePath) and some don't. Please be consistent throughout. NIT: 890: zones - zone_list seems more appropriate. fixed 911: zoneDataset is being used before being set. It could be NULL here. that should have been be_root_ds. fixed 954: To help with indentation and code maintenance, this line could be split up and if each condition isn't true then continue. This will help subsequent lines from being wrapped so much. I don't really agree here, if we do these extra indents then all of the code after that will be bumping up against the 80 character limit and will get split up to the point none of that remaining code will be readable. I'll try to clean up the line wrapping here as best I can to make it more readable. 994: This while loop seems like a good candidate for a new function, adding to code maintainability. Looks like 1096 shares this code making it an even better candidate for a function. :-) Yes that really wasn't needed there and has been removed. This while loop now only lives in the callback function. 1072: Can zhp ever be NULL? If so this line should be split up since there is no error condition for when it is NULL. I'll review be_mount.c next and send comments in a separate mail. Good point, I'll add a check to make sure it's not NULL. Thanks Tim Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can we create RAID 0 + 1 while doing jumpstart
Robert Milkowski [EMAIL PROTECTED] writes: Wednesday, October 1, 2008, 3:11:12 PM, you wrote: Can we create RAID 0 + 1 Volume(mirror) while doing jumpstart? need help on this yes, you can. Do something like: filesysmirror:d0 c0t0d0s1 c0t1d0s1 8192 / filesysmirror:d5 c0t0d0s3 c0t1d0s3 8192 /var filesysmirror:d15 c0t0d0s0 c0t1d0s0 8192 swap metadbc0t0d0s7 size 8192 count 3 metadb c0t1d0s7 size 8192 count 3 Isn't that going to be RAID 1, rather than 0+1? Boyd ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] Code review for zones support in SNAP
Tim, Thanks for the review. All comments taken as is unless noted below... thanks, -ethan Tim Knitter wrote: be_mount.c: 53: Why not add this struct to libbe_priv.h where the other structs live? Because its only used privately in be_mount.c, not anywhere else. Nit: 294, 2208: The comment should spell out variable names (altroot) for clarity sake. I think altroot is pretty well understood. Its not even used as variable name at 2208, but I could change altroot - alternate root, if that's what you were intending. 546: failed to - failed to mount a actually, the failed to just needs to be nuked. 547: dataset mountpoint - dataset. Mountpoint given the removal of the failed to portion, the sentence makes sense as is. 575: boolean_t seems a better choice since this function only has 2 states to return. Also calls to this function then don't have to compare against an int. Actually, I think this method (along with 525), need to be changed to return be_errno_t so that a more accurate message can ultimately be displayed. I'll make this adjustment. 702: Spell out altroot in comment; alternate root Again, I think altroot is well understood, but sure, I can change this... 644,715,750... zone_mounted_here the here is ambiguous, suggest just zone_mounted here means we mounted it here in this function, so we know we need to unmount it before leaving, as a cleanup task. I think its more ambiguous without the here. IMO zone_mounted sounds more like a status that the zone is currently mounted. thanks, -ethan Thanks Tim Evan Layton wrote: Hello All, We're down to the wire on the zone support changes to SNAP upgrade and are looking for code review comments. We'll be taking comments up until COB Tuesday October 7th. Your comments are as always welcome and appreciated. Defect 3686 is the blocker bug that was submitted to cover this work and the webrev is available at: http://cr.opensolaris.org/~equach/webrev.snap_zones/ Thank you in advance for your comments and help! -evan ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss Evan, I will review this today, Monday October 6. Joe ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ caiman-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss ___ zones-discuss mailing list zones-discuss@opensolaris.org
