I have been playing around with pmsapp v0.2 in my new vmware environment and I got to thinking that maybe it was possible to fence through vmware… And it is.
A bit of googling gave me this result https://fedorahosted.org/cluster/wiki/VMware_FencingConfig it turns out that the fence_vmware agent depends on the VI Perl Toolkit so I googled a bit more to find an installation guide from VMware: https://www.vmware.com/support/pubs/beta/viperltoolkit/doc/perl_toolkit_install.html
As I am working on CentOS the perl dependencies can be installed through RPMs. The following list of RPMs seems to satisfy the dependencies.
perl-Crypt-SSLeay \ perl-XML-LibXML \ perl-libwww-perl \ perl-Class-MethodMaker \ perl-devel \ perl-Test-Simple
I followed VMwares guide to build and install the VI Perl Toolkit, but afterwards it still did not work.
I got an error message saying:
fence_vmware_helper returned Undefined subroutine &Opts::add_options called at /usr/sbin/fence_vmware_helper line 82.
Googling for that error gave me this result: http://www.redhat.com/archives/linux-cluster/2011-January/msg00134.html
Basicly, I need to edit /usr/local/share/perl5/VMware/VIRuntime.pm and add:
use VMware::VILib;
above the line:
use VMware::VIM2Runtime;
Now I am able to check the status of a VM with fence_vmware
fence_vmware -o status -a vcenterserver -l [username] -p [password] -n [vmname]
Just found that my pmsapp’s present their iSCSI targets with the same SCSI_ID, this proves problematic when I want to address the disks as /dev/disk/by-id/ because all disks get represented by the same ID.
The solution is to add something like: directives. This will ensure that the disk gets a different ID.
scsi_id pmsapp_000x0001 #where x must be different on each node
to /etc/tgt/targets.conf within the