WilliamLam.com

New Updates for ghettoVCB & ghettoVCB-restore

by // 11 Comments

I know it has taken me awhile, but I finally found some time over the last week and half to go through my entire backlog of bugs, issues, feature requests, etc. and have updated both my ghettoVCB and ghettoVCB-restore script. Here is a quick summary of the new enhancements in this release:

  • ghettoVCB & ghettoVCB-restore supports ESXi 5.1
    • This was a fairly simple change by modifying the version number in the script which I noticed several users sharing the details in the VMTN forums. However, there were a few changes with the release of ESXi 5.1 that caused some initial issues which now have all been resolved in this release. For some of those details, take a look at the "Fixes" section of the change log.
  • Support for individual VM backup via command-line and added new -m flag
    • This has been requested a few times and the idea is if you have a single VM to backup, it was extra work to create a file containing the name of the VM. So now you can specify a single VM backup via the command-line
  • Support VM(s) with existing snapshots and added new configuration variable called ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP 
    •  This is probably the most requested feature I have seen and as many of you know my personal stance on snapshots, though they can be extremely useful they can also be dangerous when miss-used. I have seen too many VMTN posts about admins finding out they have a 300-500GB snapshot they need to commit and that they are also out of space/etc. However, I decided to support this use case as it was recently brought to my attention that some of the commercial backup solutions that support VMs with existing snapshots just consolidate all snapshots prior to backup. If this feature is enabled, it will consolidate ALL existing snapshots on the VM prior to running a backup.
  • Support multiple running instances of ghettoVCB running and added a new -w flag
    • Today, you can only run a single instance of ghettoVCB, there have been several requests to support running multiple instance and this was a feature submitted which allows you to specify a separate working directory for ghettoVCB. Users should try to minimize the number of instances running as there is a limited amount of resources in the ESXi Shell which can potentially impact your host. Note, this is an experimental feature.
  • Configure VM shutdown/startup order and added two new configuration variables called VM_SHUTDOWN_ORDER and VM_STARTUP_ORDER 
    • This was another submitted feature which allows you to specify the order if which VMs should be shutdown and started back up for which have a dependency between each other. 
  • Support changing custom VM name during restore
    • ghettoVCB-restore has been updated to allow for an optional 4th parameter in the restore file for users to specify an alternate VM name for the restored VM. This can be useful if want to restore the VM alongside the original VM for backup validation purposes (which everyone should do) and by disconnecting the network, you would not be impacting your existing VM while you perform your verification.
  •  Documentation updates

I highly recommend you take a look at the change log for more details (or Github diff more exact changes in the code) as well as the ghettoVCB documentation which has been updated for all the latest changes including feedback from the community. I would also like to thank the ghettoVCB/ghettoVCB-restore community for the feedback and comments you have provided as well as the following users: daviderickson, sethsp, vlooy, gvalkov, jonmchan, fryrpc and aspineux who have all submitted patches for bug fixes and feature requests via the ghettoVCB github repository

I hope you enjoy these two releases and if you run into any troubles, please post in the ghettoVCB VMTN group forum.

vCloud Suite Virtual Appliances: Passwords, Databases, URLs, etc

by // 11 Comments

I recently re-organized my home lab and I got rid of a bunch of VMs for random projects that I have been working on last year. Part of this re-organization was to re-deploy a few of the virtual appliances found within the vCloud Suite. As part of the deployment, I often find myself scouring various documents looking for default credentials to the OS, VAMI interface or the application. It is not always easy to find and I often end up going to Google or the VMTN forums for the answer.

As a fun little exercise, I thought why not deploy all of the latest virtual appliance that are available in the vCloud Suite and just document the latest usernames/passwords for the application, OS, VAMI interface, database configurations, URLs, etc.? This would primarily be a reference for myself, but thought it might also benefit others as well. Duncan Epping had done this awhile back for vCloud Director and few other virtual appliance and funny enough, his site was one of the first ones I found for the default vCloud Director password.

Not only have I deployed all the virtual appliances from the vCloud Suite, which can be seen from the screenshot below,  but I also went through each appliance and validated the credentials for the application, OS or VAMI interface if applicable as well as identify all database credentials and configurations which are not all publicly documented (this took a bit of digging in the appliances, but was not too difficult if you know where to look).

[Read more...]

What Are the Shadow of vmnic in ESXTOP?

by // 6 Comments

In ESXi 5.1, you might have noticed something new called Shadow of vmnic under the USED-BY column in the Network view of ESXTOP.

I initially heard about this from a few followers on twitter and I was curious myself since I could not find any documentation regarding this topic. It took a bit of digging but it turns out these shadow vmnics is actually related to the new VDS Health Check feature released in vSphere 5.1. A shadow port is created automatically for every uplink in your ESXi host and is used for transmitting and receiving health check related packets for each uplink. In ESXTOP, you can monitor the statistics for these shadow ports which can be used to debug/troubleshoot the network health check feature and this is why they are present.

One thing to note, these shadow ports are created regardless of whether or not your ESXi host is connected to a VDS or if you have the network health check features enabled. This is by design and there are four VMkernel modules that are responsible for the network health check feature:

  • vlanmtucheck
  • teamcheck
  • heartbeat
  • healthchk

Disclaimer: Do not modify or disable any of the above VMkernel modules else you can potentially disable network connectivity to your ESXi host (trust me, I know).

After some investigation and testing in my lab, I found that I could unload the above VMkernel modules and the shadow vmnics entries would no longer appear in ESXTOP. To do this, you will need an ESXi 5.1 host which is not running any virtual machines and you will need to run the following commands in this exact order (as there are module dependencies):

vmkload_mod -u vlanmtucheck
vmkload_mod -u teamcheck
vmkload_mod -u heartbeat
vmkload_mod -u healthchk

Once you have successfully unloaded all four VMkernel modules, if you open up ESXTOP, you should no longer see the shadow vmnics. To restore the shadow vmnics, you can either reboot (since the unload is not persistent) OR you can run the following commands in this exact order:

vmkload_mod heartbeat
vmkload_mod teamcheck
vmkload_mod vlanmtucheck

Note: By loading the heartbeat VMkernel module, it also loads the healthchk module.