Kyle McDonald wrote: > Sundar Yamunachari wrote: > >> Kyle McDonald wrote: >> >>> Sarah Jelinek wrote: >>> >>> >>>> Hi Mike, >>>> >>>> >>>> >>>> >>>> >>>>> On Thu, Jun 12, 2008 at 4:31 PM, Sarah Jelinek <Sarah.Jelinek at sun.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi All, >>>>>> >>>>>> Located at: >>>>>> >>>>>> http://www.opensolaris.org/os/project/caiman/auto_install/AI_Reqs_Final/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I would find quite helpful to be able to perform an installation into >>>>> an alternate boot environment. That is, while I am running a >>>>> production workload I should be able to perform a fresh installation >>>>> using the same profiles, rules, and pre/post automation as I would use >>>>> if I were performing a network-based installation. >>>>> >>>>> >>>>> >>>>> >>>> Are you talking a 'live' installation utilizing the AI profile? That is >>>> using the profile used to generate the initial BE on the system with AI, >>>> to install the alternate BE? >>>> >>>> >>>> >>> I know I'd like to be able to have it create a blank BE, and then >>> install it with the AI profile of my choice - and using what ever means >>> it normally uses during a net-boot-install (rules? lookups? etc) to find >>> the right profile for this host if I don't give it one. Basically a >>> net-install but without taking the machine down. >>> >>> >> Doing a net-install on a live system may not be a AI requirement. It >> is a general install RFE to support live install to an alternate BE. >> > I'm not sure what you mean by 'net-install'. Or what you thought I meant > for that matter. ;) > It is installing from a net-image. It is the most common case of AI though you can install from local media. > All I was talking about was a live 'initial' install to a new BE using > an AI profile. Preferrably the profile could be determined at run time > using the same 'logic' that a network boot based install would use on a > blank disk. > Understood. I understand what you are looking for in live install. The AI will be initiated from boot and we are not planning to run it from a live system. We plan to save the profile used for installation. It can be used to re-install the system if needed.
- Sundar > That may be what you're thinking I was saying or not, but maybe that's > clearer? > >>> >>> >>>>> There needs to be a way to specify which disk(s) to install onto. >>>>> There are two parts to this: >>>>> - It should be possible to programatically mirror the boot environment >>>>> >>>>> >>>>> >>>>> >>>> The thought here is that ZFS makes it easy to setup mirroring after the >>>> fact. So you can create a single disk boot pool and then attach a device >>>> creating a mirror later. The thing I think that needs to be considered >>>> is how AI users would want to get mirrors setup. Asking them to go to >>>> the client afterwards to setup the mirror might be the wrong thing to do. >>>> >>>> >>>> >>> Yes. I wouldn't really consider it an 'Automated Install' if I need to >>> login and attach the second mirror manually - or even automated outside >>> of AI.. >>> >>> >>>>> - If I'm performing an automated install, I should be able to ensure >>>>> that the installation goes to my intended boot drive(s), not the >>>>> drives on the SAN (which may be enumerated in such a way that the >>>>> controller number is lower than the boot disks) that contain a >>>>> database that I'd prefer not to have to restore. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Agree.. I didn't explicitly call this out, but we do intend to allow >>>> users to specify which disk to to the install on. >>>> >>>> >>>> >>>> >>> This is one area I'd like to see some innovation in. I agree with Mike >>> that I'd like to be able to tell AI to ignore my SAN disks, but at the >>> same time I'd like to not have to tweak the profile for each machine >>> tiype where the local disk might be c1t0, vs c0t0, etc. >>> >>> I don't know if this means some sort of 'local-only' or >>> 'direct-attach-only' quailfier, or a 'ignore-san', or what. But >>> basically I'd like something like the jumpstart 'rootdisk' only smarter >>> and possibly willing to take advice. For mirroring it'd be nice to have >>> an equivalent 'roormirror' that also hhad some brains on picking a good >>> second disk to mirror to. >>> >>> >> I agree that this is a big issue with automated installation. The >> suggested ideas are a good starting point. The install needs to >> distinguish between local disks and SAN disks. >> >> > And possibly (though I don't know how you'd do it... Internal vs. > External 'local' disks) > > Again, the best way (uh oh... getting in to implementation again sorry!) > might be to specify in a separate section of the profile, which > controllers and targets I want the 'automatic' selection algorithm to > consider. Many people might be able to construct a 'valid rootdisk list' > for all or most of thier hosts, or one list per host type. > > I didn't see anything in the requirements that either allows or denies > constructing the profile on the target system just before installation > (and I'm not sure it belongs in the requirements? but I'd sure feel > better seeing it there!) . That's the method (as you've probably heard > me talk about before) that I use, and I wouldn't object to constructing > the list of the disks I want considered for root disk (or mirror) > selection. depending on the hardware, I might just shove in one table in > that covered all my hosts, or i might need to select a table based on > host type, or hostname, but that kind of flexibility would be very useful. > > -Kyle > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20080613/3fcf0879/attachment.html>
