difference between vxrootmir and vxmirror

[smv]

I am running SF5.1 on sol 10 X64u7. I was able to do the root disk mirroring using the vxdiskadm menu based utility. I was trying to use the CLI alternative to vxdiskadm and found that it can be done using vxrootmir or vxmirror. I would like to know the difference between them and when to use this. Does these commands also updates the bootblock and as well as booenv.rc file and grub menu.list files? Also how to find from which disk I have booted from as prtconf -pv | grep bootpath is not yielding any output?

smv

[Marianne · Accepted solution]

From my training notes:

vxmirror – will mirror ALL partitions, including root & boot block

vxrootmir – will mirror root partition & install boot block

[Gaurav_S]

vxmirror & vxrootmirror both will install & place the boot block... however they will not be updating the grub configuration... If you call for vxassist mirror manually, that will not take care of installing boot block, its just a plain mirror ... from man page of vxmirror: The vxmirror command provides a mechanism to mirror all non-mirrored volumes that are located on a specified disk, to mirror all currently non-mirrored volumes in the specified disk group, or to change or display the current defaults for mirroring. All volumes that have only a single plex (mirror copy), are mirrored by adding an additional plex. Gaurav

[g_lee]

Gaurav and Marianne have already answered your main question regarding the differences between vxrootmir and vxmirror above.

Regarding your second question:

"how to find from which disk I have booted from as prtconf -pv | grep bootpath is not yielding any output?"

On x86/x64 you need to look for bios-boot-device, then see which device this corresponds to in biosdev, eg:

# prtconf -pv |grep boot
    bios-boot-device:  '80'
# biosdev
0x80 /pci@0,0/pci1022,7458@11/pci1000,3060@4/sd@0,0
0x81 /pci@0,0/pci1022,7458@11/pci1000,3060@4/sd@1,0
# echo |format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c1t0d0 <DEFAULT cyl 17830 alt 2 hd 255 sec 63>
          /pci@0,0/pci1022,7458@11/pci1000,3060@4/sd@0,0
       1. c1t1d0 <DEFAULT cyl 17845 alt 2 hd 255 sec 63>
          /pci@0,0/pci1022,7458@11/pci1000,3060@4/sd@1,0
[...]

ie: in this example, the machine has booted from c1t0d0

Hope that helps,

Grace

[smv]

Gaurav,Marianne and Grace thanks for the information and has helped me. Also if any one of you can point out the script which is used by the vxdiskadm "mirror disk" option to update the booenv.rc file and grub menu.list it would be helpful

smv

[g_lee]

smv,

According to the VxVM 5.1 Administrator's guide p136 (pdf link here: http://sfdoccentral.symantec.com/sf/5.1/solaris/pdf/vxvm_admin.pdf )

"On Sun x64 systems, VxVM automatically creates a GRUB menu entry for the alternate boot disk when the boot disk is mirrored. During the booting process, select the alternate GRUB menu entry from the system console.
An alternate method is to change the 'default' GRUB menu setting in the /boot/grub/menu.lst file to select this entry automatically during the booting process."

vxbootsetup is used to install the bootblk/setup the disk as a bootable system disk - however according to the man page this is called by both vxmirror and vxrootmir automatically:

http://sfdoccentral.symantec.com/sf/5.1/solaris/manpages/volume_manager/man/html/man1m/vxbootsetup.1m.html

Unfortunately I don't have an encapsulated 5.1 x64 machine to test/verify this, however the documentation does suggest that if vxmirror or vxrootmir have been used to mirror the rootdisk (ie: not vxassist mirror), that implies the bootenv and grub menu should have been updated as part of this process?

Just to be clear, which of these is the current scenario?

a) You are currently putting together a procedure to mirror using CLI instead of VxVM, so you are just trying to determine the correct equivalent commands

b) you have actually attempted mirroring via CLI (vxrootmir/vxmirror), but the bootenv.rc and grub menu list were not updated ie: you obtained different results to what was detailed in the documentation

Just trying to clarify whether you've actually had a problem, or you're asking for clarification/more details before attempting the procedure on your machine.

EDIT: the following from the VxVM 5.1 Troubleshooting Guide may also help you:

Manual GRUB procedure to set up an alternate boot disk
http://sfdoccentral.symantec.com/sf/5.1/solaris/html/vxvm_tshoot/ch03s03s02s03.htm

[smv]

Hi Grace,

Yes I am trying for option a). I don't have a physical machine for this and can't disturb the existing machine. Some are suggesting to try it on a VMWare workstation which I do have. These solaris X86 machines are new in our environment and wanted to make document regarding the build. Would like to know your opinion on this.

smv

[Gaurav_S]

Hello SMV,

the procedure & best practices you are looking for would be available in the guides above given by Grace...

You can use the guides to create your build doco as these are tested procedures by Symantec & are supposed to work in that fashion, just in case if doesn't work as expected you can always check here on forums or can raise an official support case with Symantec ...

Gaurav

[g_lee]

smv,

If you are trying to put together a procedure, then as Gaurav mentioned, it would be best to work from the VxVM Administrator's Guide and Troubleshooting Guide.

It sounds as though vxmirror will run the required steps make the mirrored disk bootable, however if you are unable to test, you can add a step into your procedure to manually check the bootenv.rc and grub menu list have been updated, and if not, use the manual procedure (in the last link) to do this separately, eg: the relevant part of your procedure would be along the lines of:

--------------------

Step X.1: Run vxmirror to mirror the root disk [add your commands/options here]

Step X.2: Check bootenv.rc and grub menu list have been updated to have root mirror as alt boot path [commands]

Step X.3: If the bootenv/grub menu have not been updated in step X.2, use the following procedure to update them manually:

http://sfdoccentral.symantec.com/sf/5.1/solaris/html/vxvm_tshoot/ch03s03s02s03.htm

--------------------

Obviously if you are able to test on a test machine, you can remove step X.3 if it's not needed; if you don't get to test beforehand then at least you will be covered/have a workaround if you need it.

Hope that helps,

Grace

[smv]

Thanks for the guidance and appreciate both of your enthusiasm shown which makes me comfortable with the product.

smv