Re: [zones-discuss] zone p2v proposal
On Sat, Dec 13, 2008 at 9:56 AM, Jerry Jelinek wrote:
> Mike Gerdts wrote:
>>
>> On Fri, Dec 12, 2008 at 6:45 PM, Jerry Jelinek
>> wrote:
>>>
>>> Mike Gerdts wrote:
On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek
wrote:
>
> The native brand installer will accept the following new arguments:
>
> -a {path} - specifies a path to an archive to unpack into the zone
> -d {path} - specifies a path to a tree of files as the source for the
> installation.
> -p- preserve system configuration (either -p or -u required).
> -s- install silently
> -u- sys-unconfig(1M) the zone after installing it
> -v- verbose output from the install process
>
> The -p, -s, -u and -v options are only allowed when -a or -d is
> provided. If -a or -d is not given, then the zone is installed using
> the
> existing mechanism.
Can an option be added to not make another copy of the data? That is,
if I have already gotten the bits in place on disk that I am happy
with, please don't copy them again (mv and "zfs set mountpoint" are OK
if needed).
>>>
>>> Mike,
>>>
>>> I'll think about that. What if -d {zonepath} just skipped the
>>> copy of the bits?
>>>
>>> Thanks,
>>> Jerry
>>>
>>
>> That sounds reasonable. This seems to imply that the argument to -d
>> will be a directory that has a subdirectory named root which is the
>> actual root of the thing to be turned into a zone.
>
> Mike,
>
> I was thinking about this more last night and I think '-d -' would be
> even simpler. It would just mean, "use the directory tree already in
> place in the zonepath".
>
> Thanks,
> Jerry
Excellent point - I like that. With this in place I think that we
will be at a point where the same flash archive that is used for
installing global zones will be nicely usable for installing full root
zones. The big bonus here is that a path toward more consistent
installation mechanisms between non-virtualized servers, zones, and
ldoms starts to be more realistic.
I am most excited about the ability to (zfs) clone the global zone to
create a master non-global zone from which future non-global zones are
cloned. On typical sun4v hardware this looks like it will cut the
time to image + create master non-global zone in half. Assuming this
plays forward in the IPS world, it means that non-global zones should
be easily created without access to the repository. This will likely
make those that are bandwidth constrained (or pay per bit) very happy.
--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Mike Gerdts wrote:
> On Fri, Dec 12, 2008 at 6:45 PM, Jerry Jelinek wrote:
>> Mike Gerdts wrote:
>>> On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek
>>> wrote:
The native brand installer will accept the following new arguments:
-a {path} - specifies a path to an archive to unpack into the zone
-d {path} - specifies a path to a tree of files as the source for the
installation.
-p- preserve system configuration (either -p or -u required).
-s- install silently
-u- sys-unconfig(1M) the zone after installing it
-v- verbose output from the install process
The -p, -s, -u and -v options are only allowed when -a or -d is
provided. If -a or -d is not given, then the zone is installed using
the
existing mechanism.
>>> Can an option be added to not make another copy of the data? That is,
>>> if I have already gotten the bits in place on disk that I am happy
>>> with, please don't copy them again (mv and "zfs set mountpoint" are OK
>>> if needed).
>> Mike,
>>
>> I'll think about that. What if -d {zonepath} just skipped the
>> copy of the bits?
>>
>> Thanks,
>> Jerry
>>
>
> That sounds reasonable. This seems to imply that the argument to -d
> will be a directory that has a subdirectory named root which is the
> actual root of the thing to be turned into a zone.
Mike,
I was thinking about this more last night and I think '-d -' would be
even simpler. It would just mean, "use the directory tree already in
place in the zonepath".
Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Fri, Dec 12, 2008 at 6:45 PM, Jerry Jelinek wrote:
> Mike Gerdts wrote:
>>
>> On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek
>> wrote:
>>>
>>>The native brand installer will accept the following new arguments:
>>>
>>>-a {path} - specifies a path to an archive to unpack into the zone
>>>-d {path} - specifies a path to a tree of files as the source for the
>>>installation.
>>>-p- preserve system configuration (either -p or -u required).
>>>-s- install silently
>>>-u- sys-unconfig(1M) the zone after installing it
>>>-v- verbose output from the install process
>>>
>>>The -p, -s, -u and -v options are only allowed when -a or -d is
>>>provided. If -a or -d is not given, then the zone is installed using
>>> the
>>>existing mechanism.
>>
>> Can an option be added to not make another copy of the data? That is,
>> if I have already gotten the bits in place on disk that I am happy
>> with, please don't copy them again (mv and "zfs set mountpoint" are OK
>> if needed).
>
> Mike,
>
> I'll think about that. What if -d {zonepath} just skipped the
> copy of the bits?
>
> Thanks,
> Jerry
>
That sounds reasonable. This seems to imply that the argument to -d
will be a directory that has a subdirectory named root which is the
actual root of the thing to be turned into a zone.
--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Mike Gerdts wrote:
> On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek wrote:
>> The native brand installer will accept the following new arguments:
>>
>> -a {path} - specifies a path to an archive to unpack into the zone
>> -d {path} - specifies a path to a tree of files as the source for the
>> installation.
>> -p- preserve system configuration (either -p or -u required).
>> -s- install silently
>> -u- sys-unconfig(1M) the zone after installing it
>> -v- verbose output from the install process
>>
>> The -p, -s, -u and -v options are only allowed when -a or -d is
>> provided. If -a or -d is not given, then the zone is installed using the
>> existing mechanism.
>
> Can an option be added to not make another copy of the data? That is,
> if I have already gotten the bits in place on disk that I am happy
> with, please don't copy them again (mv and "zfs set mountpoint" are OK
> if needed).
Mike,
I'll think about that. What if -d {zonepath} just skipped the
copy of the bits?
Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek wrote:
> The native brand installer will accept the following new arguments:
>
> -a {path} - specifies a path to an archive to unpack into the zone
> -d {path} - specifies a path to a tree of files as the source for the
> installation.
> -p- preserve system configuration (either -p or -u required).
> -s- install silently
> -u- sys-unconfig(1M) the zone after installing it
> -v- verbose output from the install process
>
> The -p, -s, -u and -v options are only allowed when -a or -d is
> provided. If -a or -d is not given, then the zone is installed using the
> existing mechanism.
Can an option be added to not make another copy of the data? That is,
if I have already gotten the bits in place on disk that I am happy
with, please don't copy them again (mv and "zfs set mountpoint" are OK
if needed).
Usage scenarios:
1) I restored a physical system from backups and need to attach it as
a zone. For example
mkdir /zones/oops
metainit d1234 -p d50 8G
echo /dev/md/dsk/d1234 /dev/md/rdsk/d1234 /zones/oops ufs 1 yes - >> /etc/vfstab
mount /zones/oops
chmod 700 /zones/oops
mkdir /zones/oops/root
use your favorite backup/restore tool to restore to /zones/oops/root
p2v it
2) Create zones as clones of /
zfs snapshot rpool/ROOT/snv_...@zonemaster
zfs clone rpool/ROOT/snv_1...@zonemaster rpool/zones/new
mkdir /zones/new/root
mv /zones/new/* /zones/new/root
p2v it, with sys-unconfig
--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Mon, Dec 08, 2008 at 01:30:18PM -0500, James Carlson wrote: > Nicolas Williams writes: > > On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote: > > > I suppose it'd be possible to look through the SMF 'privileges' for > > > the services that are still enabled, and then attempt to union those > > > into the zone privileges ... but it's unclear if that's really the > > > right approach, particularly for services that might be aware enough > > > of zones to work in some other fashion when restricted by the > > > environment. > > > > Shouldn't changes to privileges be backwards compatible? I can't quite > > tell if privilege names and semantics are intended to be Committed or > > not. > > I'm not sure what you're talking about here, but I'm not referring to > any sort of version-related compatibility issue. I'm explicitly > assuming that all such issues are dealt with by the upgrade-on-attach > feature (and that we're not yet addressing the S10-in-a-zone-on-OSOL > issue). Ah, OK. > Instead, I'm talking about the required privileges in order to enable > a given service inside a non-global zone. If a service is defined to > be run inside the zone (based on the archive presented), then someone > or something must make sure that the required privileges are granted > to the zone, or the service is going to fail. > > It's a zone configuration issue. Right. And my proposal is that services like svc:/network/nfs/server, which cannot run in NGZs should simply log and disable themselves if started in an NGZ. I.e., let the zone configuration here happen lazily. The main rationale for doing that is that it's easier to do that at runtime than at configuration time. Not only is looking into such a zone's SMF repository hard, but so is looking into its packaging (besides, the switch to IPS will make that even more obnoxious: code that needs to be thrown out later). Of course, it may be harder to fix all such services to self-disable in NGZs. > > NGZs disabling themselves, and services that can be configured > > differently to run in zones either disabling themselves or changing > > their configuration (as in your NL7C example, though why shouldn't NL7C > > be available in NGZs?). > > I don't think anyone's bothered to make it zone-aware. I wasn't proposing that it be made to be zone aware (though I gather that'd be nice). > The reason I mentioned that one is because it's an interesting example > of an edge case: "it could be in the archive being imported, but isn't > actually required for normal operation, so you can ignore it if you > don't know how to import it." Indeed. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
James, James Carlson wrote: > Presumably, as a non-native zone, if such a thing existed, it would be > expected to result in no upgrade-on-attach behavior. Right? Right, although the behavior is really dictated by the brand definition, so some sort of behavior could be defined for zone attachment. That is just theoretical, since in practice you would normally leave the zone alone since the brand module in the kernel would handle the differences between the non-global zone and the global zone. For the native brand, since there is no brand module in the kernel, the zone must be in sync. > OK. The surprise to me is that it doesn't seem to care about minor > release. I guess that's "obvious" when the mechanism is explained, > but it certainly wasn't obvious to me. 'update on attach' really only cares about syncing up the dependent pkgs between the the non-global and global zone. When crossing minor release boundaries there can be more complex stuff going on, so although it works right now for s10 to nv, going from something like s8 to s10 has some issues we'd need to figure out (e.g. pkgs changing around, no zone pkg metadata in s8, etc.). Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Jerry Jelinek writes: > > Since we (intentionally?) make branded zones available only for minor > > releases -- and not for individual KUs -- this means that the user > > should expect that he's forced into an upgrade of some sort that > > emulates patching when importing an S10 zone onto an S10 system. But > > should he expect this otherwise? When we differ by a minor release, > > there are two paths (as-is branded or upgrade to native), and it's not > > clear which gets used or should be used. > > When attaching a zone to a new system, the zone configuration's brand > dictates the behavior. For solaris8 or solaris9 branded zones, nothing > is done to the zone. For native-branded zones, either the zone is already > in sync with the global zone (making it usable) or it is not in sync > and you must use 'update on attach' to complete the migration. That's the key part I was missing -- the fact that "native" brand dictates the behavior. (Well, that and the word "patch" used in 2007/621. ;-}) I think we're in sync now. > > Or does giving the user this sort of control open the possibility for > > different zones on an S10 system that run different S10 Updates? > > We don't have a solaris10-brand at this time so the issue doesn't > apply. Yep; understood. > It sounds like you might be thinking of the following RFE: > > 646 Solaris 10 zones on OpenSolaris binary (supported) distributions Presumably, as a non-native zone, if such a thing existed, it would be expected to result in no upgrade-on-attach behavior. Right? > > I think that misses the point. I wasn't expecting "upgrade on attach" > > to do anything across a minor release boundary; I was expecting it to > > do what it does on S10, which (from a user's point of view, not an > > implementation view) is effectively upgrade the bits as though patches > > were added due to the differing patch levels of the source archive and > > the running machine. > > > > I'm surprised that it might do something different. > > Yes, it does that. I didn't mean to imply it did something different. > "update on attach" always uses the same mechanism to update pkgs within > the zone, whether the pkg varies by version number or by the patches > applied to the pkg. OK. The surprise to me is that it doesn't seem to care about minor release. I guess that's "obvious" when the mechanism is explained, but it certainly wasn't obvious to me. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
James, James Carlson wrote: > Jerry Jelinek writes: >> We can handle 'update on attach' from s10 to nv, although nv isn't an >> official release yet and something might happen which breaks this (maybe >> IPS?). We don't support 'update on attach' of s8 or s9, although I have >> played >> around with that and it kind of works. There are some other issues there >> which need to be looked at before we would support that. One thing we've >> considered, but which is not part of this proposal, is to use 'update >> on attach' to convert an S8 or S9 branded zone into a native zone >> running S10. There hasn't been any demand for that feature yet, so >> its not currently one we're working on. > > Perhaps it's "not this project," but it'd be interesting to see where > this feature set is headed. There are different possibilities, such as I've mentioned; updating s8 and s9 branded zones to native, or p2v for pre-s10 systems, or making update on attach be more like a true upgrade, or update on attach between different pkging systems (svr4 to IPS). What we actually do will depend on the demand and the priority vs. other features. > I would expect that since we support non-native brand zones, the user > has to choose (somehow) whether he wants to have his imported zone > become upgraded to the current system or whether he wants it to stay > as-is. Yes, so if you configure the zone with the 'native' brand, then that means something different than if you configure it to be a 'solaris8' or 'solaris9' branded zone. > Since we (intentionally?) make branded zones available only for minor > releases -- and not for individual KUs -- this means that the user > should expect that he's forced into an upgrade of some sort that > emulates patching when importing an S10 zone onto an S10 system. But > should he expect this otherwise? When we differ by a minor release, > there are two paths (as-is branded or upgrade to native), and it's not > clear which gets used or should be used. When attaching a zone to a new system, the zone configuration's brand dictates the behavior. For solaris8 or solaris9 branded zones, nothing is done to the zone. For native-branded zones, either the zone is already in sync with the global zone (making it usable) or it is not in sync and you must use 'update on attach' to complete the migration. > Otherwise, if he's always forced into an upgrade, then that means > branded zones eventually go away, doesn't it? No. If the zone was a solaris8 or solaris9 branded zone to begin with, then it remains that way (assuming the brand is supported on the new host). > Or does giving the user this sort of control open the possibility for > different zones on an S10 system that run different S10 Updates? We don't have a solaris10-brand at this time so the issue doesn't apply. It sounds like you might be thinking of the following RFE: 646 Solaris 10 zones on OpenSolaris binary (supported) distributions > Obviously, I'm confused. :-/ > >>> Is that correct? If so, then at least the administrative aspects of >>> patching are relevant here: the result is as though the required >>> patches were installed into the newly-attached zone, regardless of how >>> it's implemented internally. (And just as patching doesn't work >>> across minor releases, it doesn't work here.) >> When crossing a minor release boundary (like s10 to nv) all of the pkg >> version numbers change, so patches aren't a factor. We see that there >> are new versions of the pkgs, so we know those pkgs need to be updated. > > I think that misses the point. I wasn't expecting "upgrade on attach" > to do anything across a minor release boundary; I was expecting it to > do what it does on S10, which (from a user's point of view, not an > implementation view) is effectively upgrade the bits as though patches > were added due to the differing patch levels of the source archive and > the running machine. > > I'm surprised that it might do something different. Yes, it does that. I didn't mean to imply it did something different. "update on attach" always uses the same mechanism to update pkgs within the zone, whether the pkg varies by version number or by the patches applied to the pkg. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Jerry Jelinek writes: > We can handle 'update on attach' from s10 to nv, although nv isn't an > official release yet and something might happen which breaks this (maybe > IPS?). We don't support 'update on attach' of s8 or s9, although I have > played > around with that and it kind of works. There are some other issues there > which need to be looked at before we would support that. One thing we've > considered, but which is not part of this proposal, is to use 'update > on attach' to convert an S8 or S9 branded zone into a native zone > running S10. There hasn't been any demand for that feature yet, so > its not currently one we're working on. Perhaps it's "not this project," but it'd be interesting to see where this feature set is headed. I would expect that since we support non-native brand zones, the user has to choose (somehow) whether he wants to have his imported zone become upgraded to the current system or whether he wants it to stay as-is. Since we (intentionally?) make branded zones available only for minor releases -- and not for individual KUs -- this means that the user should expect that he's forced into an upgrade of some sort that emulates patching when importing an S10 zone onto an S10 system. But should he expect this otherwise? When we differ by a minor release, there are two paths (as-is branded or upgrade to native), and it's not clear which gets used or should be used. Otherwise, if he's always forced into an upgrade, then that means branded zones eventually go away, doesn't it? Or does giving the user this sort of control open the possibility for different zones on an S10 system that run different S10 Updates? Obviously, I'm confused. :-/ > > Is that correct? If so, then at least the administrative aspects of > > patching are relevant here: the result is as though the required > > patches were installed into the newly-attached zone, regardless of how > > it's implemented internally. (And just as patching doesn't work > > across minor releases, it doesn't work here.) > > When crossing a minor release boundary (like s10 to nv) all of the pkg > version numbers change, so patches aren't a factor. We see that there > are new versions of the pkgs, so we know those pkgs need to be updated. I think that misses the point. I wasn't expecting "upgrade on attach" to do anything across a minor release boundary; I was expecting it to do what it does on S10, which (from a user's point of view, not an implementation view) is effectively upgrade the bits as though patches were added due to the differing patch levels of the source archive and the running machine. I'm surprised that it might do something different. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Mike, Mike Gerdts wrote: > On Mon, Dec 8, 2008 at 12:37 PM, James Carlson <[EMAIL PROTECTED]> wrote: > >> I think answering that would answer the previous poster's question >> about the difference between doing an upgrade before flar creation and >> just importing a flar from S9: the former results in a native zone >> using this new functionality, while the latter results in a non-native >> brand without upgrade. > > I was asking under the assumption that an upgrade from a minor release > or two was supported. Typically if I am moving a S8 or S9 physical > into a zone, I really want to do an upgrade (or similar) as well. Not > being able to do this in one step is not that big of a deal - after > all I do seem to have workable alternatives: Since 'update on attach' isn't the same as a true upgrade, there are some enhancements we would need to look at in order to really make this work correctly. These are the sorts of things we might want to do as future enhancements once we have the basic s10 p2v to a native zone working. > 1) On S8 or S9, use live upgrade to upgrade to S10, then > install/attach the S10 BE as unbranded. > 2) Attach the S8 or S9 BE as a branded zone, then use live upgrade (?) > to populate a S10 BE which in turn gets installed/attached as an > unbranded zone. The first option seems like it would be workable with what we have today, plus this new p2v feature. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Mon, Dec 8, 2008 at 12:37 PM, James Carlson <[EMAIL PROTECTED]> wrote: > I think answering that would answer the previous poster's question > about the difference between doing an upgrade before flar creation and > just importing a flar from S9: the former results in a native zone > using this new functionality, while the latter results in a non-native > brand without upgrade. I was asking under the assumption that an upgrade from a minor release or two was supported. Typically if I am moving a S8 or S9 physical into a zone, I really want to do an upgrade (or similar) as well. Not being able to do this in one step is not that big of a deal - after all I do seem to have workable alternatives: 1) On S8 or S9, use live upgrade to upgrade to S10, then install/attach the S10 BE as unbranded. 2) Attach the S8 or S9 BE as a branded zone, then use live upgrade (?) to populate a S10 BE which in turn gets installed/attached as an unbranded zone. I bet I can write a script to make that look like a single command. Then, with time Jerry will follow up with a more elegant solution than duct-tape and chewing gum one I come up with. :) -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
James, James Carlson wrote: > Jerry Jelinek writes: >> James Carlson wrote: >>> "Update on attach" just means "apply saved patches, if any are >>> needed," right? >> Not really. We see what pkgs are out of sync, either because of the >> pkg version of because of patches applied to those pkgs, then we do >> something similar to uninstalling and reinstalling those pkgs into the zone, >> preserving the editable and volatile files. This causes those pkgs >> to be up-to-date with respect to the global zone, just as is the case >> when a zone is newly installed. Its a bit more complicated than that, >> but we never actually apply patches to the zone. The global zone files >> are already patched and that is the source of the files for the non-global >> zone. > > But you would _not_ do this across minor releases, so S9 installing on > S10 won't be "upgraded" nor (presumably) would S10 installing on > OpenSolaris/Nevada be upgraded at the package level. We can handle 'update on attach' from s10 to nv, although nv isn't an official release yet and something might happen which breaks this (maybe IPS?). We don't support 'update on attach' of s8 or s9, although I have played around with that and it kind of works. There are some other issues there which need to be looked at before we would support that. One thing we've considered, but which is not part of this proposal, is to use 'update on attach' to convert an S8 or S9 branded zone into a native zone running S10. There hasn't been any demand for that feature yet, so its not currently one we're working on. > Is that correct? If so, then at least the administrative aspects of > patching are relevant here: the result is as though the required > patches were installed into the newly-attached zone, regardless of how > it's implemented internally. (And just as patching doesn't work > across minor releases, it doesn't work here.) When crossing a minor release boundary (like s10 to nv) all of the pkg version numbers change, so patches aren't a factor. We see that there are new versions of the pkgs, so we know those pkgs need to be updated. > I think answering that would answer the previous poster's question > about the difference between doing an upgrade before flar creation and > just importing a flar from S9: the former results in a native zone > using this new functionality, while the latter results in a non-native > brand without upgrade. As I said, we don't currently support 'update on attach' for pre-s10 images but that might be something we could consider in the future. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Jerry Jelinek writes: > James Carlson wrote: > > "Update on attach" just means "apply saved patches, if any are > > needed," right? > > Not really. We see what pkgs are out of sync, either because of the > pkg version of because of patches applied to those pkgs, then we do > something similar to uninstalling and reinstalling those pkgs into the zone, > preserving the editable and volatile files. This causes those pkgs > to be up-to-date with respect to the global zone, just as is the case > when a zone is newly installed. Its a bit more complicated than that, > but we never actually apply patches to the zone. The global zone files > are already patched and that is the source of the files for the non-global > zone. But you would _not_ do this across minor releases, so S9 installing on S10 won't be "upgraded" nor (presumably) would S10 installing on OpenSolaris/Nevada be upgraded at the package level. Is that correct? If so, then at least the administrative aspects of patching are relevant here: the result is as though the required patches were installed into the newly-attached zone, regardless of how it's implemented internally. (And just as patching doesn't work across minor releases, it doesn't work here.) I think answering that would answer the previous poster's question about the difference between doing an upgrade before flar creation and just importing a flar from S9: the former results in a native zone using this new functionality, while the latter results in a non-native brand without upgrade. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Nicolas Williams writes: > On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote: > > I suppose it'd be possible to look through the SMF 'privileges' for > > the services that are still enabled, and then attempt to union those > > into the zone privileges ... but it's unclear if that's really the > > right approach, particularly for services that might be aware enough > > of zones to work in some other fashion when restricted by the > > environment. > > Shouldn't changes to privileges be backwards compatible? I can't quite > tell if privilege names and semantics are intended to be Committed or > not. I'm not sure what you're talking about here, but I'm not referring to any sort of version-related compatibility issue. I'm explicitly assuming that all such issues are dealt with by the upgrade-on-attach feature (and that we're not yet addressing the S10-in-a-zone-on-OSOL issue). Instead, I'm talking about the required privileges in order to enable a given service inside a non-global zone. If a service is defined to be run inside the zone (based on the archive presented), then someone or something must make sure that the required privileges are granted to the zone, or the service is going to fail. It's a zone configuration issue. Currently, there's a default set of privileges that are granted to non-global zones. It's possible to modify that set (up to a point) with 'limitpriv'. There are some that can never be granted, and if those are needed, then enabling the service just isn't going to work at all. (Unless, somehow, the service itself detects this case dynamically and falls back to some smaller set of zone-friendly features.) > NGZs disabling themselves, and services that can be configured > differently to run in zones either disabling themselves or changing > their configuration (as in your NL7C example, though why shouldn't NL7C > be available in NGZs?). I don't think anyone's bothered to make it zone-aware. The reason I mentioned that one is because it's an interesting example of an edge case: "it could be in the archive being imported, but isn't actually required for normal operation, so you can ignore it if you don't know how to import it." -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
James, James Carlson wrote: > Jerry Jelinek writes: >> Mike Gerdts wrote: >>> This implies that the source system can be S8, S9, or S10. I don't >>> see anywhere else in the proposal that explicitly states that S8 and >>> S9 can be attached and upgraded, so I suspect I am reading my wishes >>> into your words. >> That was not my intention. I'll reword this. The source system must >> be a S10 or above (something that zone "update on attach" will handle). > > "Update on attach" just means "apply saved patches, if any are > needed," right? Not really. We see what pkgs are out of sync, either because of the pkg version of because of patches applied to those pkgs, then we do something similar to uninstalling and reinstalling those pkgs into the zone, preserving the editable and volatile files. This causes those pkgs to be up-to-date with respect to the global zone, just as is the case when a zone is newly installed. Its a bit more complicated than that, but we never actually apply patches to the zone. The global zone files are already patched and that is the source of the files for the non-global zone. >> Where possible, things will be disabled, but for SMF services delivered >> in hollow pkgs, those services must be removed due to the way the SMF >> dependencies are defined. Disabling those services doesn't work. V2P is > > What maps packages to SMF services? (I'm guessing it's a matter of > seeing the manifests in a hollow package and then reading the > manifests to determine what services they deliver, and disabling > those. Is that right ... ?) Yes, thats the idea. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Jerry Jelinek writes: > Mike Gerdts wrote: > > This implies that the source system can be S8, S9, or S10. I don't > > see anywhere else in the proposal that explicitly states that S8 and > > S9 can be attached and upgraded, so I suspect I am reading my wishes > > into your words. > > That was not my intention. I'll reword this. The source system must > be a S10 or above (something that zone "update on attach" will handle). "Update on attach" just means "apply saved patches, if any are needed," right? > Where possible, things will be disabled, but for SMF services delivered > in hollow pkgs, those services must be removed due to the way the SMF > dependencies are defined. Disabling those services doesn't work. V2P is What maps packages to SMF services? (I'm guessing it's a matter of seeing the manifests in a hollow package and then reading the manifests to determine what services they deliver, and disabling those. Is that right ... ?) -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote: > > I am not planning on making any automated changes to the privileges > > available > > to the zone. If this turns out to be an important issue, then we could > > look at that as a possible future enhancement. The problem I see is that > > we don't have any data to automatically drive which services and apps need > > which privs. > > Right; that's what I was getting at. We don't carry that sort of > metadata around in any convenient form. > > I suppose it'd be possible to look through the SMF 'privileges' for > the services that are still enabled, and then attempt to union those > into the zone privileges ... but it's unclear if that's really the > right approach, particularly for services that might be aware enough > of zones to work in some other fashion when restricted by the > environment. Shouldn't changes to privileges be backwards compatible? I can't quite tell if privilege names and semantics are intended to be Committed or not. In any case, even if privilege names and semantics not stable, surely services can discover incompatible changes (e.g., if a service's method_context refers to invalid privilege names then SMF can discover this), and services that drop/retain specific privileges too will fail. So at least the failures should be obvious. No, I don't know how best to deal with such situations. > There are other things that work like this, such as ZFS delegations or > in network configuration, so there might be a broader issue here in > configuring the zone so that it can properly accept the archive. I'm > not saying that I think it's unusable, but rather that there may be > non-trivial cases here where a good bit is left to the user's > imagination. And if the image itself expects to have zones... Yes, some things can break, but maybe we should design the system so that using a system image as a zone root should just work, with services that can't run in NGZs disabling themselves, and services that can be configured differently to run in zones either disabling themselves or changing their configuration (as in your NL7C example, though why shouldn't NL7C be available in NGZs?). Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Nico, Nicolas Williams wrote: > On Mon, Dec 08, 2008 at 10:14:26AM -0700, Jerry Jelinek wrote: >> Yes, not everything that runs in the global zone works in a >> non-global zone. NFS serving or non-global zones are the most obvious >> examples. >> >> For SMF services, the services to be deleted are the the ones >> delivered in SVr4 pkgs with SUNW_PKG_HOLLOW=true since that matches >> what happens when a zone is installed using the existing technique. > > Why detect and delete them? That sounds like a lot of pointless work. Because the zone won't boot until those services are deleted. That doesn't seem pointless. The whole idea is to try to provided an automated tool which simplifies the task of p2v-ing a system into a zone. If 100% of these migrations will fail, then solving that problem seems to be within the scope of the tool. We have the pkg metadata which tells us which services should not be run inside the zone, so I guess its not clear to me why we would deliberately ignore that. > Better leave them alone -- let them discover that they are not in the > global zone and fail to start accordingly (and disable themselves, and > log approapriately). Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Mon, Dec 08, 2008 at 10:14:26AM -0700, Jerry Jelinek wrote: > Yes, not everything that runs in the global zone works in a > non-global zone. NFS serving or non-global zones are the most obvious > examples. > > For SMF services, the services to be deleted are the the ones > delivered in SVr4 pkgs with SUNW_PKG_HOLLOW=true since that matches > what happens when a zone is installed using the existing technique. Why detect and delete them? That sounds like a lot of pointless work. Better leave them alone -- let them discover that they are not in the global zone and fail to start accordingly (and disable themselves, and log approapriately). Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Mike, Mike Gerdts wrote: >> The image modifications fall into the following areas: >> 1) SMF services that are not usable within a zone should be deleted or >>disabled as necessary (for S8 and S9 we dealt with rc scripts >> instead). > > This implies that the source system can be S8, S9, or S10. I don't > see anywhere else in the proposal that explicitly states that S8 and > S9 can be attached and upgraded, so I suspect I am reading my wishes > into your words. That was not my intention. I'll reword this. The source system must be a S10 or above (something that zone "update on attach" will handle). > Will config files be removed or will services just be disabled (and > hollow packages removed)? That is, will "destructive" things be done > that prevent the implementation of some future v2p (e.g. zone to ldom > or xen) transition? Or is it believed that the typical packages that > are not appropriate for non-global zones lack configuration that would > be interesting in a p2v -> v2p world? Where possible, things will be disabled, but for SMF services delivered in hollow pkgs, those services must be removed due to the way the SMF dependencies are defined. Disabling those services doesn't work. V2P is something we've talked about but is outside the scope of this specific proposal. In general we'll try to leave enough info behind so that a future v2p could be done, but that automated tool won't be part of this initial project. Also, hollow pkgs are not removed. Those pkgs appear to be installed within zones. It is just the SMF services delivered by those pkgs which will be removed. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Jerry Jelinek writes:
> > Can a user predict what these automatic changes will be? After
> > import, is there a log of the changes or "adjustments" made?
>
> I assume you really mean which SMF services will be off, since
> the other changes are listed here in the case?
Exactly.
> We can describe which
> SMF services will be deleted or disabled in general terms, but we
> really want this to be driven by the pkg metadata itself. We'll probably
> also have a list of some well-known 3rd party services that don't work
> inside a zone, such as vxvm, which we'll turn off. As with the S8 and
> S9 brands, there may need to be some manual tweaking of the services
> as part of the p2v process, although we've generally had good results
> with the S8 and S9 brands without a lot of manual work.
I can understand that some tweaking would end up being necessary, but
at least an outline of what's affected (if known) would probably be
good to include with the case materials.
> There will also be a log file for this p2v process. I'll add that info to
> the case.
OK.
> > S10 has a number of new features over S8 and S9. How do these factor
> > in? For instance, what happens to the privileges required in order to
> > run the services contained in an archive? (The user might need to
> > configure the zone so that the right set of non-default privileges are
> > granted. Is there some new way to do this, or does the user need to
> > trouble-shoot failing services?)
>
> I am not planning on making any automated changes to the privileges available
> to the zone. If this turns out to be an important issue, then we could
> look at that as a possible future enhancement. The problem I see is that
> we don't have any data to automatically drive which services and apps need
> which privs.
Right; that's what I was getting at. We don't carry that sort of
metadata around in any convenient form.
I suppose it'd be possible to look through the SMF 'privileges' for
the services that are still enabled, and then attempt to union those
into the zone privileges ... but it's unclear if that's really the
right approach, particularly for services that might be aware enough
of zones to work in some other fashion when restricted by the
environment.
There are other things that work like this, such as ZFS delegations or
in network configuration, so there might be a broader issue here in
configuring the zone so that it can properly accept the archive. I'm
not saying that I think it's unusable, but rather that there may be
non-trivial cases here where a good bit is left to the user's
imagination.
(Then there are other cases, such as NL7C. You might possibly want to
use that if you're in the global zone, but since you can't use it in a
non-global zone, and since the web server itself is perfectly
serviceable _without_ NL7C, translating over means simply removing
that from the configuration. I'm guessing that sort of thing is a
manual operation.)
> >> -a {path} - specifies a path to an archive to unpack into the zone
> >> -d {path} - specifies a path to a tree of files as the source for the
> >> installation.
> >
> > Just for clarification: does that '-d {path}' option point to a system
> > root? Could I use "lumount" to mount up an inactive BE and turn it
> > into a zone?
>
> Yes, -d points to a system root, so your idea of turning a BE
> into a zone should work just fine.
OK; should point out that this is intended to be a system root. (I
know, it should be "obvious," but since I had to ask anyway ...)
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
On Mon, Dec 8, 2008 at 9:43 AM, Jerry Jelinek <[EMAIL PROTECTED]> wrote: > SUMMARY: > > This fast-track enhances the Solaris Zones [1] subsystem to address an > existing RFE [2] requesting a "physical to virtual" (or p2v) capability > for installing native-branded zones based on an existing system image. > > This capability is very similar to what already exists for solaris8 and > solaris9 branded zones [3,4], which are installed using an archive of an > existing system image, but in this case there is no brand module and the > zone brand is 'native'. > > Patch binding is requested for this native p2v capability. The > stability of these interfaces is documented in the interface table below. > > DETAILS: > > This new feature is primarily an extension to the native-brand zone > installation code so that the zone can be installed using an archive of a > system, as is already done with the solaris8 and solaris9 brands. > However, because there is no brand module, part of the installation > process > uses the zone "update on attach" [5] feature to sync the zone image up > so that it is usable on the system. Because "update on attach" does not > allow zone downgrades, the system image being installed and p2v-ed must > not > be newer than the host OS release or the installation will fail with an > error. > > In addition to the "update on attach" during zone installation, there are > a variety of other modifications which must be applied to the image so > that > it is usable within a zone. Again, this is very similar to what happens > today with the solaris8 and solaris9 brands during installation. > > The image modifications fall into the following areas: > 1) SMF services that are not usable within a zone should be deleted or >disabled as necessary (for S8 and S9 we dealt with rc scripts instead). This implies that the source system can be S8, S9, or S10. I don't see anywhere else in the proposal that explicitly states that S8 and S9 can be attached and upgraded, so I suspect I am reading my wishes into your words. Assuming the S8 and S9 are supported source systems, is there any real difference in the resulting zone if the following paths are taken: src-s9# lucreate -c s9 -n s10 ... src-s9# luupgrade -s /mnt/s10media -n s10 ... src-s9# luactivate s10 src-s10# flarcreate ... /net/server/src-10.flar dst-s10# zoneadm install -a /net/server/src-10.flar ... vs. (upgrade on attach - not branded) src-s9# flarcreate ... /net/server/src-9.flar dst-s10# zoneadm install -a /net/server/src-9.flar > 2) Network configuration must be adjusted depending on if the zone is >shared-stack or exclusive. > 3) NFS serving must be disabled [6]. > 4) The vfstab must be adjusted so that local file systems from the > original >system are disabled. > 5) Any zones installed on the original system will be uninstalled and >deleted from the image (zones do not nest). > > All of these modifications happen transparently as part of the zone > installation, as is the case with the solaris8 and solaris9 brands. Will config files be removed or will services just be disabled (and hollow packages removed)? That is, will "destructive" things be done that prevent the implementation of some future v2p (e.g. zone to ldom or xen) transition? Or is it believed that the typical packages that are not appropriate for non-global zones lack configuration that would be interesting in a p2v -> v2p world? -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Bill Walker wrote: > > Tjere are some SMF services known to break when moving into a zone from > a physical server. Things like sysevent, FMA-ish stuff, ldom manager, > etc. (I don't have my notes in front of me, but I seem to remember > around 4-5 from a SUNWall vanilla installation). Mostly stuff tied to > the hardware platform itself. Bill, Things like sysevent or FMA stuff are delivered in hollow pkgs, so we know that those services should not exist inside the zone and we'll get rid of them. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Tjere are some SMF services known to break when moving into a zone from
a physical server. Things like sysevent, FMA-ish stuff, ldom manager,
etc. (I don't have my notes in front of me, but I seem to remember
around 4-5 from a SUNWall vanilla installation). Mostly stuff tied to
the hardware platform itself.
I had a customer ask about the BE idea just a couple weeks ago. :)
bill.
James Carlson wrote:
> Jerry Jelinek writes:
>> 1) SMF services that are not usable within a zone should be deleted or
>> disabled as necessary (for S8 and S9 we dealt with rc scripts
>> instead).
>> 2) Network configuration must be adjusted depending on if the zone is
>> shared-stack or exclusive.
>
> Depending on what the original archived server once did, it seems at
> least possible that some of the changes that occur here could cause
> damage to the services that the image will provide when run inside a
> zone.
>
> Can a user predict what these automatic changes will be? After
> import, is there a log of the changes or "adjustments" made?
>
> S10 has a number of new features over S8 and S9. How do these factor
> in? For instance, what happens to the privileges required in order to
> run the services contained in an archive? (The user might need to
> configure the zone so that the right set of non-default privileges are
> granted. Is there some new way to do this, or does the user need to
> trouble-shoot failing services?)
>
>> -a {path} - specifies a path to an archive to unpack into the zone
>> -d {path} - specifies a path to a tree of files as the source for the
>> installation.
>
> Just for clarification: does that '-d {path}' option point to a system
> root? Could I use "lumount" to mount up an inactive BE and turn it
> into a zone?
>
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
James,
James Carlson wrote:
> Jerry Jelinek writes:
>> 1) SMF services that are not usable within a zone should be deleted or
>> disabled as necessary (for S8 and S9 we dealt with rc scripts
>> instead).
>> 2) Network configuration must be adjusted depending on if the zone is
>> shared-stack or exclusive.
>
> Depending on what the original archived server once did, it seems at
> least possible that some of the changes that occur here could cause
> damage to the services that the image will provide when run inside a
> zone.
Yes, not everything that runs in the global zone works in a
non-global zone. NFS serving or non-global zones are the most obvious
examples.
For SMF services, the services to be deleted are the the ones
delivered in SVr4 pkgs with SUNW_PKG_HOLLOW=true since that matches
what happens when a zone is installed using the existing technique.
> Can a user predict what these automatic changes will be? After
> import, is there a log of the changes or "adjustments" made?
I assume you really mean which SMF services will be off, since
the other changes are listed here in the case? We can describe which
SMF services will be deleted or disabled in general terms, but we
really want this to be driven by the pkg metadata itself. We'll probably
also have a list of some well-known 3rd party services that don't work
inside a zone, such as vxvm, which we'll turn off. As with the S8 and
S9 brands, there may need to be some manual tweaking of the services
as part of the p2v process, although we've generally had good results
with the S8 and S9 brands without a lot of manual work.
There will also be a log file for this p2v process. I'll add that info to
the case.
> S10 has a number of new features over S8 and S9. How do these factor
> in? For instance, what happens to the privileges required in order to
> run the services contained in an archive? (The user might need to
> configure the zone so that the right set of non-default privileges are
> granted. Is there some new way to do this, or does the user need to
> trouble-shoot failing services?)
I am not planning on making any automated changes to the privileges available
to the zone. If this turns out to be an important issue, then we could
look at that as a possible future enhancement. The problem I see is that
we don't have any data to automatically drive which services and apps need
which privs.
>> -a {path} - specifies a path to an archive to unpack into the zone
>> -d {path} - specifies a path to a tree of files as the source for the
>> installation.
>
> Just for clarification: does that '-d {path}' option point to a system
> root? Could I use "lumount" to mount up an inactive BE and turn it
> into a zone?
Yes, -d points to a system root, so your idea of turning a BE
into a zone should work just fine.
Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zone p2v proposal
Jerry Jelinek writes:
> 1) SMF services that are not usable within a zone should be deleted or
> disabled as necessary (for S8 and S9 we dealt with rc scripts
> instead).
> 2) Network configuration must be adjusted depending on if the zone is
> shared-stack or exclusive.
Depending on what the original archived server once did, it seems at
least possible that some of the changes that occur here could cause
damage to the services that the image will provide when run inside a
zone.
Can a user predict what these automatic changes will be? After
import, is there a log of the changes or "adjustments" made?
S10 has a number of new features over S8 and S9. How do these factor
in? For instance, what happens to the privileges required in order to
run the services contained in an archive? (The user might need to
configure the zone so that the right set of non-default privileges are
granted. Is there some new way to do this, or does the user need to
trouble-shoot failing services?)
> -a {path} - specifies a path to an archive to unpack into the zone
> -d {path} - specifies a path to a tree of files as the source for the
> installation.
Just for clarification: does that '-d {path}' option point to a system
root? Could I use "lumount" to mount up an inactive BE and turn it
into a zone?
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org
