Thursday, October 17, 2013

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.

Thursday, May 16, 2013

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.

Friday, April 05, 2013

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

Thursday, March 28, 2013

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! )

changing opnsense mtu

 note to self When an OpnSense is deployed on Proxmox environment where MTU is <1500, it doesn't seem to auto-detect and leaves the O...