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 OpnSense unreachable over the web-ui.

One of the easiest methods to get around this is to console on to the opnsense and use ifconfig command to set the interface IP temporarily with the required MTU (Ref) > Connect to the web-ui and then put in the custom MTU again under the interface settings.

java security exceptions

note to self

Found somewhat easy way to get around the annoying java security settings. Simply add the destinations preceded by http:// and/or https:// to below text file, one per line. Make sure that there are no white spaces at the end of the line.

C:\Users\USER\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

NTFS read-write on Mac

I had no clue it was this complicated when i thought of copying some files on to a portable hard drive from a Mac, for a colleague. As it turned out, Mac has ntfs support but default behavior is to only allow read-only access.

After searching around for a good while finally came across this nice tool called "Mounty for NTFS" which did the trick for me. I'd highly recommend to check it out if you happen to run in to the same problem and not so familiar with Mac way of things -like me.

Google will easily find it for you, but here is a link to the site.

http://enjoygineering.com/mounty/

VMware SRM stuff

note to self

Came across this weird error and spent a good amount of time searching around with not much luck. As it turned out, lot of time could have been saved with a simple reboot of the vCenter server appliance.

SRM 5.8
vCenter Server Appliance 5.5, vSphere Web Client

SRM was fully functional when accessed via one of the vCenters while other gave error "getAttribute: Session already invalidated" when provided the credentials to access the remote vCenter.

A simple reboot of the problematic vCenter brought everything back to normal state, many hours later. When in doubt, reboot is the lesson i suppose.

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

lvm stuff

note to self

Encountered "Found duplicate PV" warning again, i keep forgetting the solution for some reason. Good KB article is here. Idea is to filter out everything that has multiple device files leaving only one, and making sure the one that is left is the best one to be used. For example, in a multipath environment filter out everything except the multipath'd device node created by the device-mapper or whichever multipath tool that is used. ( Eg. /dev/emcpowera etc. ) Once the changes are in place pvscan and vgscan can be issued and check the warning appears no longer. Example filter rule from the current SLES san-boot setup this was tested is below. It filters out everything except /dev/dm-* devices which are the multipath devices created by device mapper.

filter = [ "a|/dev/dm-.*|", "r|.*|" ]

Once this is tested, mkinitrd should be done to put the changes in to the initrd image to be activated at the boot.