WilliamLam.com

Magikmon MKBackup for ghettoVCB

by // 1 Comment

I was contacted awhile back ago by Alain Spineux, about his MKBackup utility and he was in the very early stages of integrating the software with my ghettoVCB script. Per Alain's website:

MKBackup is a free front-end for common backup tools like MS Windows ntbackup, and it successor wbadmin, Un*x tools like tar, but also popular ghettoVCB to backup Virtual Machine on VMware ESX(i) host.

MKBackup is developed in Python and is available for Microsoft Windows, for Linux and other Un*x systems.

MKBackup is driven by a CLI and jobs are defined in an INI file. Its main feature is to send an email report including log files and all hints that could help the user to estimate the real status of the backup.

It looks like Alain has done some more work and the recently released version 0.9.3. You can get a better overview of the tool at his website and there is also a dedicated support forum.

I have personally not used MKBackup, but it could be very useful and compliment ghettoVCB. Not only can you schedule backups on a Windows or UNIX/Linux host using MKBackup, but it also generates backup reports based on the output from ghettoVCB logs. The reports can then be monitored using a soon to be released utility called MagiKmon which can provide email alerts on successful or failed backups.
 
Here are a few screenshots that Alain has kindly provided with the use of the latest version of ghettoVCB:

Categories // Uncategorized Tags //

Script: Updated ghettoVCB and ghettoVCBg2 to Support vSphere 4.1

by // 21 Comments

Check out the latest update to both ghettoVCB and ghettoVCBg2, which now supports vSphere 4.1! There are no new features introduced with these updates but ghettoVCB does include additional logging and debugging functionality to help identify issues that may arise. Unfortunately, with ghettoVCBg2 I had to perform some additional code changes due to undocumented changes in vMA's vi-fastpass Perl library. This initially caused the script to break and the reason was deprecated methods that were removed in the latest release of vMA 4.1. Luckily the fix was not too bad and I had to spend a few hours looking at the new methods that were implemented.

Hopefully everyone enjoys these two releases and if you run into any troubles, please post in respective script's forum.

vMA 4.1 - Authentication Policy (fpauth vs adauth)

by // 5 Comments

I recently wrote an article about vMA 4.1 and Active Directory Integration and today I noticed there were some confusion on the expected behavior of the two types of authentication policy: vi-fastpass authentication versus Active Directory authentication. There are actually a few things to consider:

  • What user context are you trying to execute a command against a target?
  • What authentication policy was used to add the target to vMA?
  • Is vMA host joined to an Active Directory Domain?
USER CONTEXT FPAUTH or ADAUTH vMA in AD DOMAIN
vi-admin fpauth no
DOMAIN\username adauth yes

I will try to explain the following two scenarios listed above.

In this example, vMA was not joined to an Active Directory Domain and we are adding a vCenter target to vMA using a local administrator account on vCenter server (by default, fpauth is assumed):

[vi-admin@tancredi ~]$ sudo vifp addserver manaslu.primp-industries.com
Enter username for manaslu.primp-industries.com: administrator
*protected email*'s password:
This will store username and password in credential store which is a security risk. Do you want to continue?(yes/no): yes

We can verify the target was added using fpauth by running the following command:

[vi-admin@tancredi ~]$ vifp listservers -l

esx4-1.primp-industries.com ESX fpauth
esxi4-3.primp-industries.com ESXi fpauth
manaslu.primp-industries.com vCenter fpauth

Next, we will set the fastpass target to the newly added vCenter server:

[vi-admin@tancredi ~]$ vifptarget -s manaslu.primp-industries.com

[vi-admin@tancredi ~][manaslu.primp-industries.com]$

If we run "esxcfg-nics -l" against an ESX(i) host that is being managed by this vCenter, we would do the following (note: user context is vi-admin):

[vi-admin@tancredi ~][manaslu.primp-industries.com]$ esxcfg-nics -l --vihost esxi4-3.primp-industries.com

Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 02:00.0 e1000 Up 1000Mbps Full 00:50:56:ac:69:95 1500 Intel Corporation PRO/1000 MT Single Port Adapter

In this first example, we are relying solely on vi-fastpass authentication, where a vi-adminXX account is created on the target. The credentials to this account is generated by vMA and stored in the local credential store.

In this example, vMA has been joined to an Active Directory Domain and we are adding a vCenter target using Active Directory credentials:

[vi-admin@tancredi ~]$ sudo vifp addserver reflex.primp-industries.com --authpolicy adauth
Enter username for reflex.primp-industries.com: PRIMP-IND\primp

Note: As of writing this, there is a typo in vMA 4.1 documentation on the syntax to use when specifying the username when prompted. You will need to use DOMAIN\username, if you decide to use the --username, then you need to add a second "slash" to escape the first (e.g. DOMAIN\\username)

We can verify the target was added using adauth by running the following command:

[vi-admin@tancredi ~]$ vifp listservers -l

esx4-1.primp-industries.com ESX fpauth
esxi4-3.primp-industries.com ESXi fpauth
manaslu.primp-industries.com vCenter fpauth
reflex.primp-industries.com vCenter adauth

Next, we will set the fastpass target to the newly added vCenter server but before we do so, we need to login to vMA using a valid Active Directory account.

[primp@tancredi ~]$ vifptarget -s reflex.primp-industries.com

[primp@tancredi ~][reflex.primp-industries.com]$

Now if we run "esxcfg-nics -l" against an ESX(i) host that is being managed by this vCenter, we would do the following (note: user context is DOMAIN account):

[primp@tancredi ~][reflex.primp-industries.com]$ esxcfg-nics -l --vihost himalaya.primp-industries.com

Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 06:00.0 e1000e Up 1000Mbps Full 00:30:48:d9:58:6a 1500 Intel Corporation 82574L Gigabit Network Connection
vmnic1 07:00.0 e1000e Down 0Mbps Half 00:30:48:d9:58:6b 1500 Intel Corporation 82574L Gigabit Network Connection

In this second example, we are relying solely on Active Directory authentication, where credentials of the user that is logged into vMA are being used. Unlike in the first example, if you were in the vi-admin context and tried to execute the same command, you will notice you are prompted for credentials. This is the intended and expected behavior of the two scenarios.

However, if you do not want to join vMA to an Active Directory Domain but would still like to perform an unattended authentication from vi-admin context, then you need to setup a Kerberos ticket for the target. The details on configuring this is outlined in vMA 4.1 user guide, please refer to the document for more details.

One thing to note which I actually ran into, is that when you join your vMA host to Active Directory Domain, you must reboot vMA after joining to the domain. If you do not, you will run into issues when trying to add a target using adauth authentication policy.