VIBE on Linux

[#1]

Hey folks,

Has anyone managed to get VIBE running on Linux? I've tried it on RHEL4 and RHEL5 and after installing all of the requisite Perl modules it always fails to authenticate with Virtual Center.

I downloaded and installed the Windows binary version of VIBE and it works fine using the same arguments and authentication.

I'm obviously missing some magic to getting this working.

Thanks for any help,

Richard

[#2]

Hello Richard,

I understand your plight, which is why the first thing I'd like for you to confirm on this is whether you're being firewalled or blocked in any manner on your host.

Best ways to initially test that would be to validate whether you can RSH and SSH to the ESX Server as well as your storage - Just to be sure.

Also, if you reference p16 of the VIBE User Guide, it might provide some insight into your problem.

(Worst case, I'd also collect the debug data referenced on p16 to confirm if that would help your issue)

Check out the User Guide, and also confirm nothing is blocking you to square that away.

http://now.netapp.com/NOW/knowledge/docs/olio/guides/vibe/VIBE_User_Guide.pdf

Look forward to hearing from you, and a speedy resolution to your issue!

Christopher

[#3]

I'm quite sure this isn't a firewall issue because I can connect fine from my Windows laptop. I can SSH fine to the ESX servers but VIBE needs a connection to the Virtual Center server. Here's the output from the script with debugging and verbose:

# ./vibe-1.0.3.pl --verbose --debug --backup --vcip 10.254.20.59 --vcuser Administrator --sauser root --ds MC-PROD-DATA-01 --saip 10.254.20.200
Perl module NaServer (ZAPI) not available, --protocol rsh required.
Perl module NaErrno (ZAPI) not available, --protocol rsh required.
logStartReport(): LOG REPORT FOR VIBE
logStartReport(): -----------------------------------------------------
logStartReport(): VIBE Version: 1.0.3
logStartReport(): Log Filename: /NetApp/VIBE/Report/VIBE_20080729_091209.log
logStartReport(): Backup Start Time: Tue Jul 29 09:12:09 2008
runCheckArgs(): WARNING: --vcpasswd not defined on command line.
Enter password for Virtual Center 10.254.20.59, user Administrator:
runCheckArgs(): WARNING: --sapasswd not defined on command line.
Enter password for storage appliance(s) (username for all: root):
runCheckArgs(): Datastore(s) selected: MC-PROD-DATA-01
runCheckArgs(): Datastore snapshot prefix will be used (VIBE_ds_snap).
runCheckArgs(): Command line arguments successful.
runLogin(): Initializing connectivity to Virtual Center and storage appliances.
runLogin(): Converting Virtual Center hostname to IP address ...
runLogin(): Attempting to ping Virtual Center 10.254.20.59 ...
runLogin(): Ping of Virtual Center 10.254.20.59 successful.
runLogin(): Testing login to Virtual Center 10.254.20.59 ...
runLogin(): ERROR: Virtual Center login failed -- check authentication and firewall settings!
runExit(): Exiting with return code: 16

[#4]

Richard,

The firewall issue I was thinking of possibly wasn't on the Virtual Center side, but more of on the Linux side

If you review the logfile it reports in that dump - does it have any apparent reference to what exactly isn't connecting or communicating?

logStartReport(): Log Filename: /NetApp/VIBE/Report/VIBE_20080729_091209.log

If I were in this same situation (trying to trace out this issue) I'd either sniff traffic or confirm which ports my host was attempting to connect remotely on - so as to be able to validate if it my specific host who is having a problem connecting on a port/protocol, or if I am experiencing a failure of the script itself.

Then given that, if it isn't a connection issue - we could find out whether we might be having a Perl issue with a specific module used for this.

My thought would be, that if we're experiencing a specific issue with a module, it might be bound to the "SoapFault" function, which is also referenced with the vmware script "vminfo.pl" and in a worst case scenario - testing if that script works (or fails) would be a good way to validate that particular function.

Being that we have one host (Windows) which works, and one (Linux) that does not, initially it tends to look like a host-bound issue on the Linux side.

Hopefully this was helpful Richard,

Thanks and let us know!

Christopher

[#5]

The log file contains exactly what I posted from running the script with the verbose option, above. tcpdump shows HTTPS traffic in both directions between VIBE and the Virtual Center server. Running vminfo.pl works fine with the same credentials...

# /root/viperltoolkit/apps/vm/vminfo.pl --server 10.254.20.59 --username Administrator

Enter password:

....<listing of all virtual machines>...

I'll keep digging.

Thanks,

Richard

[#6]

We've seen this be a problem in a couple of cases with using the wrong VI Perl Toolkit. If you aren't using 0.9 or 1.0 (preferably 1.0) then this would happen. If you try to use 1.5 you will likely have problems.

There's a new version coming out very shortly (1.0.4) which will have the 1.5 VI Perl Toolkit support included. In the meantime, you can get the 1.0 VI Perl Toolkit from:

http://www.vmware.com/support/developer/viperltoolkit/

Thanks,

--Matt

[#7]

Version 1.0.8 is available on the NOW ToolChest. Give that version a try and let me know if you have the same problem. Note that it requires the VMware API 2.5 libraries now.

Thanks,

--Matt

[#8]

Matt,

I appreciate the update. I've too much else going on and not had a chance to look into this. Right now we have VIBE running under Windows on the VI server and that is acceptable for the time being.

Thank you,

Richard