Netbackup stuff

note to self

Came across an issue recently on a media server. Issue seems to be related to robotic control and not the drives. In this setup, the media control host was not the media server which experienced the issue. tpconfig and vmoprcmd outputs from the problematic media server were as below. Notice the "AVR" for drives in vmoprcmd output, which indicates an issue with the robotic control.

bash-3.00# ./tpconfig -l
Device Robot Drive       Robot                    Drive                Device     
Type     Num Index  Type DrNum Status  Comment    Name                 Path       
robot      3    -    TLD    -       -  -          -                    ECC-QAS
  drive    -    0  hcart    1      UP  -          IBM.ULT3580-TD4.000  /dev/rmt0.1
  drive    -    1  hcart    2      UP  -          IBM.ULT3580-TD4.004  /dev/rmt1.1
  drive    -    2  hcart    3      UP  -          IBM.ULT3580-TD4.003  /dev/rmt2.1
  drive    -    3  hcart    4      UP  -          IBM.ULT3580-TD4.002  /dev/rmt3.1

bash-3.00# ./vmoprcmd -d

                                PENDING REQUESTS

                                     

                                  DRIVE STATUS

Drv Type   Control  User      Label  RecMID  ExtMID  Ready   Wr.Enbl.  ReqId
  0 hcart    AVR                -                     No       -         0  
  1 hcart    AVR                -                     No       -         0  
  2 hcart    AVR                -                     No       -         0  
  3 hcart    AVR                -                     No       -         0  

                             ADDITIONAL DRIVE STATUS

Drv DriveName            Shared    Assigned        Comment                   
  0 IBM.ULT3580-TD4.000   Yes      -                                         
  1 IBM.ULT3580-TD4.004   Yes      -                           
  2 IBM.ULT3580-TD4.003   Yes      -                                         
  3 IBM.ULT3580-TD4.002   Yes      -     

As it turns out, it was a simple issue of media server not being able to identify the media control host name. It was set up to use /etc/hosts for resolution, and someone had removed the entry for the media control host! 



Frustrating that the error is not specific enough to identify where the problem is..I guess checking if the media control host, master/emm etc. communication and name resolution as the first step in these type of cases would save a few hours.

LVM stuff

note to self

Came across some useful information on storage migrations with lvm, when searching around. Tested again and seems to be working fine on RHEL6, need to make sure same goes for RHEL4 somehow.

http://storagemeat.blogspot.com/2010/07/migrating-volumes-with-linux-lvm.html
http://www.sandelman.ca/mcr/blog/lvm/
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/mirrorrecover.html
http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/mirrorrecover.html

ethX adapter names getting incremented in Ubuntu on VMware

note to self

Came across this issue with a P2Vd Ubuntu system. Network interface name seemed to get incremented eth0 >eth1 >eth2 and so on, each time a new adapter is added even when the old one is removed.

It is caused by the udev rule to persist device names with the hardware id located in  /etc/udev/rules.d/70-persistent-net.rules

This blog here helped to figure it out.

Useful Veeam KBs

note to self

Surebackup Ping Test TimedOut

http://www.veeam.com/kb1067

How to log in to the Virtual Proxy Appliance

http://www.veeam.com/kb1447

Platespin Migrate on RHEL

note to self

We had a requirement to convert a number of workloads on RHEV (Red Hat Enterprise Virtualization) environment to vSphere. This is so far unsupported with the vSphere converter tool, and it fails to at the initial step of querying the source system when attempted, complaining about not being able to detect volumes on the source system. (On RHEV, scsi disks are detected as /dev/vdX devices, could be one of the reasons.)

After trying at it for a while, we decided to give PlateSpin Migrate a go, and the results were quite satisfying.

Setting up and starting a workload "copy" is quite straightforward, but could get tricky at times if the source system is running GNU/Linux. (RHEL etc.) PlateSpin supports file based and block based copy methods and for Linux workloads, only the block based method is supported if the migration is to happen while the source is online. Block based copy method depends on a custom kernel module -which has to be build manually, if PlateSpin doesn't come with a matching one for the current kernel.

Process is explained in detail on the below link.

http://www.novell.com/support/kb/doc.php?id=7005873

During the conversion, if it throws an error similar to "Could not load driver: Exec format error", then probably the kernel module is not built compatible to the currently running kernel.

To make sure a built module is supported on the current kernel, without going through the trouble of packaging it for PlateSpin, it can be inserted to the running kernel manually. Inserting should not return any error. Loaded module can be viewed and then removed to clean up, by below commands in the order given.

insmod blkwatch.ko

lsmod | grep blkwatch

rmmod

Even though it looks like a bit more complicated than the vSphere converter, In my opinion, PlateSpin does a far better job! It will be interesting to see how it will handle a conversion where the kernel it self has to be replaced with a different one to be able to run on the destination platform. (eg. Xen to vSphere )

vCenter Converter Standalone P2V Fail

note to self

vCenter standalone converter 5.0.1-875114 (latest as of 03-2013) still seems to be having this issue with P2V on systems with using the VLAN tagging at the OS level. Culprit seems to be the "dot" (.) in the interface name.

This has been witnessed, identified and workaround suggested by a number of people and the article that helped me is here. Simply turning off those interfaces before the conversion, you can proceed to convert the system -if that is a possibility. If not, you can try the alternative suggested on the same link above, by changing how the interface is named ( VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD )

I witnessed the issue with few RHEL5.4 systems, but was unable to replicate the same on the RHEL5.8. Perhaps the issue has some dependancy on a OS component which has been updated on the later releases on RHEL. ( not so sure! )