Ron, Solaris was not reliable 15 years ago and it is not reliable even today. Drivers and handling drivers have not been tackled at any level.
I would agree with you or anyone who says a reboot should be a part of handling the new encapsulated disks for mounted partitions on a disk. -GGR On Mon, Mar 3, 2008 at 2:34 AM, Ronald S Karr <[EMAIL PROTECTED]> wrote: > When I first wrote the script (many, many, many moons ago), Solaris wasn't > reliable about getting the disk driver to update its view of the partition > table, which would cause confusion in some cases, so when I wrote this stuff > I was overly conservative. But, even now, it is a bit tricky trying to > prove that none of the partitions are in use, particularly from a shell > script (and vxencap is a shell script). > > Fixing the script to avoid reboots has been discussed quite a few times, > but nobody has wanted to prioritize tackling a script like this that > developers have been updating for over 15 years. > -- tron |-<=>-| > > On Mar 2, 2008, at 10:25 AM, Asim Zuberi wrote: > > Hi Rajiv / Ron -- > > Thanks for your responses and your assistance in explaining me the > concepts of reboot required for encapsulation. > > Rajiv -- Actually, I've tried your proposed suggestion already. I used a > non-root-disk to encapsulate by using > "/etc/vx/bin/vxencap" command. The command ran clean, but it didn't > encapsulate the root drive. I couldn't boot the > system to complete the encapsulation process. > > As Ron has pointed out in his email the script /etc/init.d/vxvm-reconfig > handles the encapsulation, which does reboot > the system. Maybe it is time for VRTS developers to modify the > encapsulation process without a reboot so that this > can be achieved on the fly. > > The reason I am enquiring the details of the encapsulation process is > because of capturing Solaris Zones under VxVM > control. To make Solaris Zones part of VxVM every time a zone is created, > making it impossible to reboot the physical > system so often. So we're looking into options where a reboot of the > physical can be avoided. > > Question is has someone already identified a process to accomplish this > task? I'd be happy to try out the trials and share > the workarounds if I get some pointers from VRTS engineers on this mailing > lists. > > > > thanks! > --Asim; > > > > > ------------------------------ > *From:* Rajiv Gunja [mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>] > > *Sent:* Friday, February 29, 2008 7:10 PM > *To:* Ronald S Karr; Asim Zuberi; [EMAIL PROTECTED] > *Subject:* Re: [Veritas-vx] encapsulation requires a reboot - why? > > Asim, > > I am no Veritas expert, but speaking only from logic, here is how I see > fit to answer you: > > > 1. Encapsulation of a disk is done on disks which are NOT under > Veritas control, but is in the system. > 2. Encapsulating a disk on the system requires a reboot ONLY if the > said disk has current slices mounted and/or has applications running on it. > 3. Encapsulation/Veritas take over of a disk usually done for disks > which are single and you need a way to expand or create software mirror of > the disk. > > > Hope this sheds some light on your question. So the next test you need to > do is to encapsulate a disk which has no mounted slices and see if it > requires a reboot. > > -GGR > > On Fri, Feb 29, 2008 at 4:59 PM, Ronald S Karr <[EMAIL PROTECTED]> wrote: > > > Encapsulation is done by the script /etc/init.d/vxvm-reconfig. This > > handles a variety of things, some of which can only be handled during > > a reboot, when everything is clean. If none of those things are going > > on, you could run /etc/init.d/vxvm-reconfig. But, this script will > > reboot your system automatically if you encapsulate a volume that is > > in use, so be careful. Don't expect any sympathy from support if this > > doesn't go well. > > -- > > Ronald S. Karr > > tron |-<=>-| [EMAIL PROTECTED] > > > > On Feb 29, 2008, at 10:06 AM, Asim Zuberi wrote: > > > Thanks to the following for their quick responses > > > > > > Pat Owens > > > Darren Dunham > > > > > > Follow-up question: If I am encapsulating a non-root disk, such as a > > > data > > > disk, it appears I still need to reboot the entire > > > physical system. Is there a work around to avoid a reboot of the > > > physical > > > system, if only a data disk is being encapsulated? > > > > > > For testing purposes, I attempted to encapsulate a slice of a non- > > > root disk > > > on a system by using /etc/vx/bin/vxencap command. > > > The command ran clean but the encapsulation didn't take place until > > > a reboot > > > occurs. > > > > > > Please advise. > > > > > > thanks! > > > --Asim; > > > > > > > > > > > > > > > =] -----Original Message----- > > > =] From: [EMAIL PROTECTED] > > > =] [mailto:[EMAIL PROTECTED] On > > > =] Behalf Of Asim Zuberi > > > =] Sent: Friday, February 29, 2008 8:48 AM > > > =] To: [EMAIL PROTECTED] > > > =] Subject: [Veritas-vx] encapsulation requires a reboot - why? > > > =] > > > =] > > > =] > > > =] hi All -- > > > =] > > > =] Why the process of encapsulation (of a disk) requires a > > > =] reboot of the system? > > > =] Is there a way, it can be avoided? > > > =] > > > =] thanks! > > > =] --Asim; > > > =] > > > =] _______________________________________________ > > > =] Veritas-vx maillist - Veritasfirstname.lastname@example.org > > > =] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx > > > =] > > > > > > _______________________________________________ > > > Veritas-vx maillist - Veritasemail@example.com > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx > > > > _______________________________________________ > > Veritas-vx maillist - Veritasfirstname.lastname@example.org > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx > > > > > Ronald S. Karr > tron |-<=>-| [EMAIL PROTECTED] > > > >
_______________________________________________ Veritas-vx maillist - Veritasemail@example.com http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx