Virtual SCSI Mapping Through HMC rather than "mkvdev" CLI

This post shows an easy wat to perform mapping of disk between the Virutal Server and Virtal Client though Hardware Management Console. Rather than CLI using "mkvdev".

Disadvantage of thie method. Only directy mapping of the disk could be made rather than mapping a logical volume or a filesystem are not supported in this method. In those case we need to go back "mkvdev" mode for the mapping.

So we assume that a disk has been mapped the VIO_Server from the SAN Side.

Login into HMC-->System Management-->Server(Managed System to which the VIO_Server and VIO_Client Belongs to)-->Configuration-->Virtual Resources-->Virtual Storage Management.

This opens a windows like below.

In the window, on the left hand top corner you would find a drop down called "VIOS". Select the appropriate VIO_Server. This would list all the physical volumes available on the VIO_Server. To begin with the mapping. Select the disk that you would like to assign and click on "Modify Assignment" on the left hand bottom corner.

This the next window that will open upon selecting "Modify Assignment". Select the appropritate "Virtual SCSI Server Adapter" (vhost#) and click "OK".

Now the mapping is done.

Cloning rootvg to external disk_AIX_ : Mapping to VIO_Client: Part III

VIO_Server

$ lsdev -virtual or $ lsdev | grep "vhost*" or $ lsdev -type adapter : List all the virtual adapters on the VIO_Server.

$ lsmap -vadapter vhost* : Show the mapping of the Virtual SCSI Server Adapter.

$ lspv : Command to list the Physical Volumes.

$ mkvdev -vdev hdisk# -vadapter vhost# : Command to provide mapping between the virtual SCSI Server and Client Adapter.

$ lsmap -vadapter vhost : Command to verify the mapping has been done or not.

VIO_Client:

Now boot the disk through SMS Mode from HMC. Which would boot the client from the "cloned" disk. Upon successful installation of the Operating System. Login into the client.

# lspv : List all the physical volume.

Cloning rootvg to external disk_AIX_ : Mapping to VIO_Client: Part II

Now inform the storage team to map the concerned LUN to the VIO_Server by providing the WWN of the HBA attached to the VIO_Server. Once it is done.

Login into the VIO_Server as "padmin".

$ cfgmgr : Configuration Manager.

$ lspv : List the Physical volumes in the VIO_Server.

$ chkdev -dev hdisk# -verbose : Command to get the PVID, IEEE ID, Unique ID of the disk and VIO_Attributes.

Now check the "unique_id" of the disk which we made a note earlier and compare it with the "unique id" displayed in the above command. If the "unique id" matches then the proper "LUN" is mapped else need to check with the storage team to map the correct LUN.

Next step would be create a Virtual_SCSI_Server_Adapter on VIO_Server and Virtual_SCSI_Clinet Adpater on the VIO_Client.

This has been explained in my previous posts.

Login into HMC--> System Management-->Server-->Select the VIO_Server-->Configuration--> Manage Profile-->Actions-->Create-->Virtual SCSI Adpater.

Make a note of Adapter ID and ensure VIO_Server_Adapter in mapped to the correct VIO_Client.

Follow the same process at the VIO_Client end as well.

Mapping between VIO_Server and VIO_SCSI...Part III

Cloning rootvg to external disk_AIX_ : Mapping to VIO_Client: Part I

The method which we are going to discuss is "rootvg" is cloned on a LUN. Now the LUN is mapped to a VIO_Server which is then presented to a VIO_Client.

Rootvg Cloning:

# lspv : Command to list the physical volumes in the box.

# bootinfo -b : Command to find the boot disk.

# bootinfo -s hdisk# : Command to find the size of the disk.

Now select an empty of same size of the boot disk for cloning. Make sure the physical volume selected has "uniquq id"

# lsattr -EHl hdisk# | grep -i "unique" : Command to view the unique id of the disk and make a note of id.

# alt_disk_copy -d hdisk# : Command to create OS cloning.

# lsvg : Command to view all the volume groups.

The name of the clonend volume group "alt_inst_rootvg".

The bootlist is automatically updated upon successfull cloning of the rootvg. Which puts "alt_inst_rootvg" as primary bootvolume and the other one as secoundary volume group.

Now we go ahead in removing the cloned rootvg disk (SAN) volume from the server.

# rmdev -dl hdisk# : Command to remove the cloned rootvg disk from the server.

# bootlist -m both -o hdisk# : Make sure the bootlist is updated properly. So that the machine boots from the "rootvg" rather then cloned. Since the cloned one is removed from the disk.

If the rmdev command shows an error. We can remove the cloned by disabling.

# alt_rootvg_op -S -t hdisk3 : Command to disable the cloned rootvg.

Now the cloning part is completed. Next We move to VIO_Server side configuration......Part II

Import and Export of a Volume Group in IBM AIX and Hp_Unix

Import and Exporting process to removing a Volume Group and its configuration. This can be used to remove a Volume  Group from a machine otherwise to export a volume group from one machine and use it on another machine.

# lspv : List the physical volumes.

# lsvg -o : List active volume groups in the machine.

Prior to exporting a volume group we need to make sure that the volume group is not active. So its has to be deactivated which in turn all the file system has to be unmounted.

# lsvgfs <volume_group_name> : Command to list the filesystem on the volume group.

Before Unmountig the filesystem, check the status of the filesystem.

# fuser -cu <filesystem> : Shows the process and user using that filesystem.

# kill -9 <PID> : Kill corresponding process.

# umount /filesystem : Unmount the filesystem.

# varyoffvg <volume_group_name> : Deactivate the volumegroup name.

# lsvg -o  : Ensure the volume group is not active.

# exportvg <volume_group_name> : Command to export the volume group.

Eventhough the concept of volume group refers to removing the Volume Group but not its configuration.  That everyvolume group has its own configuration stored in /etc/lvm/lvm.conf. And the volume group information is also updated in the VGDA on each physical volume that was a part of exported volume group.

That why when you try create a volume group from a physical disk that was a part of exported volume group shows  error "Physical volume belongs to a volume group".

In that case we use the option "-f" to create a volume group. Otherwise we can remove the disk definition from the ODM and reconfigure it.

# rmdev -l hdisk#  : Command puts the disk into defined state.
# rmdev -dl hdisk# : Command removes the ODM information about the disk.
# cfgmgrf -l hdisk* : Command to redefine the disk.

Now, will get back to exporting the volume group. The exported volume group can be imported on the same machine or not to different machine.

In case of moving to a different machine. Disk has to be removed physically and in case of LUN. Mapping has to be done o the WWN of another server. Once it is done. Login into the another server,

# lsdev -Cc disk : Look for the disk.

# lspv : List the newly allocated disk. The disk remains in "none" state.

# importvg -y <volume_group_name> <physical_volume_name> : Command to import a volume group.

Since the VGDA on the physical volume plays a vital role in importing the volume group.
"-y" option specifies, what should be the name of the imported volume group. In the option is not specified then the volume group imported with the default name "vg##".

"-n" : Flag can be used to syncronize the imported volume group.
"-V" : Flag specifies the given major number of the imported volume group.

# lvlstmajor : Command to view the list of free major numbers.

HP_Unix..continued...

Good to know about the I-nodes in Hp_Unix

Consider the scenario, where you have a filesystem called "/myfile" which was mounted onto a logical volume called "/dev/vg00/lvol1" that belongs to the volume group "vg00".

In this case. Every file and directory created in UNIX environement will have unique "i-node" value. But there are cases for directories to have the same "i-node" value.

So, is there any chance of a "Single" directory to hold two different "i-node" values.

Let me explain what is "i-node" ?

I-node is a pointer variable which holds address and other other attributes of an object. Where the object is referred to an file or directory.

So I-node is composed of ( File/Directory creation time, modified time, access time, its metadata, owner of the object, group of the object, permissions, location of the file/directory on the disk).

Now I am asked to craete a file sytem. First I would intialize the phyical volume.

# pvcreate /dev/rdsk/c0t0d1

Now I create volume group and logical volume.

# vgcreate myvolume /dev/dsk/c0t0d1

# lvcreate -L 512M -n mylogical myvolume

Now the logcial volume is created. Next I go ahead to format the logical volume.

# newfs -F vxfs /dev/myvolume/rmylogical

Now I create a mount point i.e., a directory.

# mkdir /myfile : This makes the OS to allocate an i-node to this directory.

# cd /

# ls -il | grep -i myfile : Now obtain the i-node of the created directory. It shows a value of "1234".

Now I proceed in mounting the file system.

# mount /dev/myvolume/mylogical /myfile

# bdf : Verify the filesytem is mounted and # cd /myfile confims "lost+found" as well.

Now I am trying to get the i-node of the same directory "/myfile" which is now acting as mounting point.

# cd /

# ls -il | grep myfile : Now it shows a different value. The value is the inode value of the "root" filesystem.

So when the same filesystem is unmounted.

# umount /myfile

Now if you try to get the "i-node" value of the directory "/myfile" it will show "1234".

Replacing a disk in the LVM environment

Scenario:

In the LVM scenario, we want to replace hdisk2 in the volume group vioc_rootvg_1, which contains the LVs vioc_1_rootvg associated to vtscsi0. It has the following attributes:

 

 

 

> The virtual SCSI adapter on the virtual I/O server is vhost0.

 

On the VIO_Client:

1) # unmirrovg rootvg hdisk1 : Unmirror the failing disk.

2) # bosboot -ad /dev/hdisk0 : Create a bootimage on hdisk0.

3) # boolist -m both -o hdisk0 : Change the boot order.

4) # reducevg -d -f rootvg hdisk1 : Remove the failing disk from the rootvg

5) # rmdev -dl hdisk1 : Command to remove the disk from the machine.

Now the disk can be removed from the VIO_Server:

The "hdisk1" is presented at the VIO_Client as the logical volume of name "vioc_1_rootvg" that belongs to the volume group called "vioc_rootvg_1" that is made up of physical volume hdisk2 at the VIOS end.

Since the hdisk1 is the failed disk which has to be replace, which in turn refer to a logical volume at the VIOS. We need to remove the logical volume.

Note: The logical volume is associated with the Virtual Targer Device "vtscsi0" and mapped to the virtual client SCSI Adapter "vscsi1".

1) Login into VIOS_Sever as padmin.

2) $ lslv vioc_1_rootvg  : Make a note of the size of the LV (No.of LP/PP Counts).

3) $ rmdev -vtd vtscsi0 : Command to remove the Virtual Target Device.

4) $ rmlv -f  vioc_1_rootvg  : Command to remove the logical volume.

5) $ lsvg -lv vioc_rootvg_1 : Command to verify the logical volume has been remove from the volume group.

6) $ mklv -lv vioc_1_rootvg vioc_rootvg_1  32G: Command to recreate another logicalvolume of same size.

7) $ lslv vioc_1_rootvg  : Command to verify the logical volume has been created.

8) $ mkvdev -dev vioc_1_rootvg  -vadapter vhost0  : Mapping of the logical volume to the Virtual SCSI client adapter.

9) $ lsmap -vadapter vhost0 : Verify the mapping has been done successfully.

On the client:

1) # cfgmgr : Command to look for any new devices added.

2) # lspv : List the physical volumes. Look for the one in "None" state.

3) # extendvg rootvg hdisk# : Command to add the new disk to the rootvg.

4) # mirrorvg rootvg hdisk# : Command to mirror the rootvg to the newly added disk.

5) # lsvg -m rootvg  : Command to verify the rootvg is mirrored onto new disk.

6) # bosboot  -ad /dev/hdisk# : Create a boot image on the newly added disk.

7) # bootlist -m both -o hdisk# : Update the bootlist.

> The volume group on the virtual I/O client is rootvg.

> The virtual SCSI adapter on the virtual I/O client is vscsi1.

> The failing disk on the virtual I/O client is hdisk1.

> The virtual disk is LVM mirrored on the virtual I/O client.

> The size is 32 GB.