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. ;)
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. 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
