manual root encapsulation question

Hi,

I want to encapsulate my root disk, as a last step before reboot, using the
vxencap command after configuring the rest of my storage system volumes.

Is there a need to use vxconfigd -m disable and vxdctl enable just before
the command?

Me <me@hotmail.com> wrote:
>Root Encapsulation is a longer process than you woud think.
>
>1. Create a private area on the disk to keep Volume Manager information
>
>     Sounds easy, but you need at least 1 cylinder for this, and if 
>there is none, then Volume Manager will "borrow" a piece of swap.
Great

>potential for people to mess this up.
>
>2. Create the subdisks (and plexes) around current partitions
>    This bit is simple if you've done bit 1. and you know what you're
doing.
>
>3. Create volumes. Sounds simple, but root volume as to have a special 
>minor number (0) , otherwise it will not work.
>
>4. Now comes the tricky bit. You will have to save the old vfstab, put a

>new one in place and put a couple of entries into the /etc/system file 
>(assuming this is Solaris)
>
>
>
>So, in short , do vxdiskadm, select the option to do root disk 
>encapsulation, sit back, watch it reboot twice and come up in good order
>
>
>
>To answer your questions about vxdctl enable and vxcondifd -m disable.
>
>
>vxconfigd is the daemon that holds the Volume Manager configuration in 
>memory. You start it with the "vxconfigd" command, and you control
it 
>(after startup) with the vxdctl command.
>
>vxconfigd -m disable
>
>will start the configuration daemon in disabled mode.
>
>
>vxdctl enable
>
>
>will switch a running vxconfigd into enable mode
>
>Assaf wrote:
>> Hi,
>> 
>> I want to encapsulate my root disk, as a last step before reboot,
using
the
>> vxencap command after configuring the rest of my storage system
volumes.
>> 
>> Is there a need to use vxconfigd -m disable and vxdctl enable just
before
>> the command?
>> 
>> Thanks


Thanks for the answer... in my tests, all I did was to run vxencap command
, reboot the host and everything was fine... I have no problem that my swap
is a little bit less than the original...

Is the vxconfigd -m disable (before the vxencap) will be neccasary to assure
that  no configuration change will be available because I'm going to reboot
the host in a moment?

one more thing sometime I get return code 0 after the vxencap command but
the disk wasn't encapsulated... is there a possibilty of old veritas config
data saved on the disk or somewhere that vxvm recognize? how can I clean
it from a live root disk?

Thanks

Root Encapsulation is a longer process than you woud think.

1. Create a private area on the disk to keep Volume Manager information

     Sounds easy, but you need at least 1 cylinder for this, and if 
there is none, then Volume Manager will "borrow" a piece of swap.
Great 
potential for people to mess this up.

2. Create the subdisks (and plexes) around current partitions
    This bit is simple if you've done bit 1. and you know what you're doing.

3. Create volumes. Sounds simple, but root volume as to have a special 
minor number (0) , otherwise it will not work.

4. Now comes the tricky bit. You will have to save the old vfstab, put a 
new one in place and put a couple of entries into the /etc/system file 
(assuming this is Solaris)



So, in short , do vxdiskadm, select the option to do root disk 
encapsulation, sit back, watch it reboot twice and come up in good order



To answer your questions about vxdctl enable and vxcondifd -m disable.


vxconfigd is the daemon that holds the Volume Manager configuration in 
memory. You start it with the "vxconfigd" command, and you control it

(after startup) with the vxdctl command.

vxconfigd -m disable

will start the configuration daemon in disabled mode.


vxdctl enable


will switch a running vxconfigd into enable mode

Assaf wrote:
> Hi,
> 
> I want to encapsulate my root disk, as a last step before reboot, using
the
> vxencap command after configuring the rest of my storage system volumes.
> 
> Is there a need to use vxconfigd -m disable and vxdctl enable just before
> the command?
>