WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Datastore File Management using vCLI vifs

03.09.2012 by William Lam // Leave a Comment

There are many useful scripts that are bundled with the VMware vCLI, one such script, that is not very well known is the vifs utility which provides datastore file management. When you right click on a datastore and browse using the vSphere Client, you can create a new folder, download/upload, delete and move files.

Using the vCLI's vifs utility, you can perform the same set of operations via the command-line and behind the scenes it uses the vSphere API fileManager to perform these operations. You can also browse datastore by just having access to a web browser, just point it to the following address: https://[ESXI_HOSTNAME]/folder and you can access the datastores by clicking through the links.

To browse the datastore using vifs, you will need vCLI installed on either a Windows/Linux system or you may use VMware vMA.

To browse a specific datastore for an ESXi host, you will need to first list the available datastores by using the following command: vifs --server [SERVER] --username [USERNAME] --listds

Once you have identified the datastore you are interested in, you will then use the --dir flag to list the contents of the directory and their sub-directories by using the following command: vifs --server [SERVER] --username [USERNAME] --dir '[DATASTORENAME]'

Note: The format of the datastore name must be in brackets '[datastorename]' which is how a datastore path is identified in the vSphere API. To list sub-directories, you will need a space between the datastore name and the directory name and do not forget to quote the parameter

Let's say you would like to download the .vmx configuration file for in the directory, you can use --get flag to by using the following command:

vifs --server [SERVER] --username [USERNAME] --get '[DATASTORENAME] somedir/somefile.vmx'

Note: In the example above, we are downloading the file in the current working directory denoted by the "." (period). If you wish to download it somewhere else or even renaming the file, you will need to specify the full path to the destination


If you wanted to automate the downloading of say all .vmx configuration files, it might be pretty tedious to run through the directory discovery, so here is a quick shell script called getVMVMX.sh that is more user friendly that allows you to easily download all .vmx configurations for a given datastore.

To use the script, you will need vCLI installed on either a Linux system or use VMware vMA and be sure to set the executable permission on the shell script. You will need to specify the credentials to the ESX(i) host and the specific datastore you wish to either "list" or "download" all .vmx configuration files.

Using the --listds flag, you will need to identify the datastore you wish to use. Next you will use the following command to "list" all .vmx configuration file: ./getVMVMX.sh [ESXI_SERVER] [USERNAME] "[PASSWORD]" [DATASTORE] list

To download all .vmx configuration file you will use the following command:

./getVMVMX.sh [ESXI_SERVER] [USERNAME] "[PASSWORD]" [DATASTORE] download [FOLDER]

where FOLDER is a directory that will automatically be created for you to store all .vmx configuration files

Note: You can easily modify the script to add an additional "for loop" at the beginning to automatically download .vmx configurations for all datastores. I will leave that as an exercise for the reader.

So if you ever need to grab a vmware.log file for a specific VM or upload an ISO to datastore, you can do so from the command-line using the vifs utility that is bundled with the vCLI.

Categories // Uncategorized Tags // ESXi 4.1, ESXi 5.0, ESXi 5.0, vcli, vSphere

Ruby vSphere Console (RVC) 1.6 Released

02.13.2012 by William Lam // 10 Comments

Rich Lane the creator of Ruby vSphere Console just recently released RVC 1.6 which includes some new features and bug fixes. If you are a current RVC user, you can update to the latest version by using the "gem" utility. For those of you who are not familiar with RVC, it is console UI for vCenter Server and ESX(i) host and it provides a way to interact with your vSphere infrastructure like the vSphere Client but using a console shell. RVC can be installed on a Windows, Linux or Mac OSX system and it's built on RbVmomi which is an open source Ruby library/bindings to the vSphere API.

I recently spent sometime revising RVC as it has gotten a significant amount of new features from the last time I looked at it. RVC currently has over 120+ commands that simplify some of the most common tasks such as cloning a VM (Full & Linked Clone), vDS Management, Cluster/Host/VM Management and many many others.

There are so many cool and unique features that RVC offers that I could not name them all, but I thought I share with you my top 5 favorite features of RVC.

1. vSphere Virtual Filesystem
RVC presents the vSphere infrastructure as a virtual filesystem, this allows you to quickly navigate your Hosts, Cluster, Datacenter, VMs, etc. in a very user friendly and intuitive manner. It also allows for tab completion of commands and the use of wild cards when referring to objects.

Here is an example of connecting to a vCenter Server and quickly building out a new infrastructure by creating a new datacenter, cluster, adding an ESXi host and then creating a Linked Clone VM in just seconds:

Here is another example of what can be done with the virtualFS that Rich has created, you can easily view or edit files within the datastores (e.g. .vmx,.vmdk,vmware.log).

2. Multi-vCenter Support

You can connect to multiple vCenter Server(s) at once and quickly navigate to any of your vCenter Servers to perform various operations. Each vCenter will have it's own constructed virtual filesystem that will show up when you login.

Here is an example of connecting to 4 different vCenter Servers:

3. Performance Graphs
You can view performance charts using RVC similar to the vSphere Client. RVC quickly allows you to see what performance metrics are relevant for an object and displaying the graph using gnuplot:

Here is an example of displaying the live "cpu.usagemhz.average" metric for an ESXi host:

4. Marks
You can think of marks like an alias, RVC allows you to quickly save your favorite paths for later use and also include them within commands. This can be really helpful if you do not want to keep typing out a super long path and just give it a short and easy name to remember.

Here is an example of creating a mark called "favVM" to a particular VM in my vSphere infrastructure and perform a linked clone operation using the mark I created:

5. Extensibility

RVC as Rich stated does not (yet) have every single capability that the vSphere Client has, but is extremely extensible. Anyone with a bit of Ruby and vSphere API knowledge can extend or create new commands for RVC. It it modular in nature and when you create/extend a new command, you do not necessary need to add it to the original RVC source code. You can actually add your *.rb files into the .rvc directory in your home directory and RVC will automatically pickup the commands you added. If you create some cool and useful new commands, be sure to send them to Rich via the github project so he can include it in the main branch.

Here is an example of extending two new commands for "cluster" object. There are currently only three cluster commands by default: add, configure_ha and create. You may have noticed that configuring DRS is not one of the available commands, but wouldn't it be nice to have it? I created two new commands called "configure_drs" and "configure_automationlevel" which allows you to enable/disable DRS for a cluster and also specifying the DRS automation level.

Here is the source code for two commands that were added in .rvc/cluster.rb

# William Lam
# http://www.virtuallyghetto.com/

## Command to Enable/Disable DRS ## 

opts :configure_drs do
  summary "Configure DRS on a cluster"
  arg :cluster, nil, :lookup => VIM::ClusterComputeResource
  opt :disabled, "Disable DRS", :default => false
end

def configure_drs cluster, opts
  spec = VIM::ClusterConfigSpecEx(
    :drsConfig => {
       :enabled => !opts[:disabled],
    }
  )
  one_progress(cluster.ReconfigureComputeResource_Task :spec => spec, :modify => true)
end

## Command to Configure DRS Automation Level ###

opts :configure_automationlevel do
  summary "Configure DRS Automation level on a cluster"
  arg :cluster, nil, :lookup => VIM::ClusterComputeResource
  arg :level, "DRS Automation Level [fullyAutomated|manual|partiallyAutomated]"
end

def configure_automationlevel cluster, level
  spec = VIM::ClusterConfigSpecEx(
    :drsConfig => {
       :defaultVmBehavior => level,
    }
  )
  one_progress(cluster.ReconfigureComputeResource_Task :spec => spec, :modify => true)
end

 
Note: This was my first time writing any Ruby code, I'm sure I could have combined the two operations with some conditionals and then create the property drsConfig object.

If these five features of RVC seems really cool, I would highly recommend you go download and install RVC and give the rest a spin. If you have any feedback, questions or want to submit a patch for the RVC project, be sure to check out the RVC github project page for all the details.

Categories // Uncategorized Tags // ruby vsphere console, rvc, vSphere

When Do vSphere MoRef's Change?

11.26.2011 by William Lam // 20 Comments

I received a few follow-up questions from my earlier article vSphere MoRef (Managed Object Reference) ID Finder Script regarding when the MoRef (Managed Object Reference) ID changes. As mentioned in my previous article, a MoRef ID is guaranteed to be unique within a vCenter instance to track all entities such as virtual machines, hosts, datacenters, resource pools, etc. and this is stored within the vCenter Database. One thing that I did not mention in the other article, is there is also a MoRef ID for objects that reside directly on an ESX(i) host. The scope of a MoRef ID on an ESX(i) host is only within the host itself, this is another reason why it is a best practice to use vCenter to not only manage your inventory but also keeping track of a single consistent global MoRef ID.

An entities MoRef ID will remain the same throughout it's lifespan unless it is destroyed or unregistered from vCenter Server (e.g. virtual machine or host). With a MoRef ID on an ESX(i) host, this will slightly change with vSphere operations such as vMotion and/or Storage vMotion of a virtual machine in which the VM will be unregistered and re-registered on a completely different host.

Here are a few examples demonstrating some vSphere operations and what happens to MoRef ID:

1. vMotion of a VM from HostA to HostB

As you can see, the vCenter MoRef ID stays the same during the vMotion, but the MoRef ID on the hosts will change as the VM changes hosts.

2. Storage vMotion of a VM's disk while residing on the same host (HostB)

With Storage vMotion, the vCenter MoRef ID stays the same as one would expect, but the MoRef ID on the hosts still changes because start with vSphere 4.x, a Storage vMotion starts off just like a vMotion and hence a new VM entity is registered on the same host.

3. Clone of VM1 to VM2

Since vCenter is creating a new VM entity, a new MoRef ID will be generated as expected.

4. FT of VM

Just like with a clone, an FT'ed VM will contain two unique entities on each local ESX(i) host and hence a different MoRef ID will be found, but still only a single MoRef ID in vCenter.

5. Deleting VM1 and creating a new VM with same name as VM1

Again, since the entity was destroyed and re-created with the same name, it is treated as a new object and hence a new MoRef ID will be assigned to the entity, even if it has the same name. This is true if you remove an ESX(i) host from vCenter and re-add it, all information including the MoRef will be re-generated. 

Lastly, you might ask if one could modify or set a MoRef ID for an entity in vCenter since it is stored in the vCenter Database? The answer is no. The MoRef ID is stored in the vCenter Database but there are many internal pointers that uses the MoRef ID, especially when it comes to VM MoRef IDs. Just updating the ID in one location will not suffice and can cause integrity issues with your vCenter Database, not to mention it is not supported by VMware.

However, there is one way you could influence the algorithm on how the MoRef ID's are generated. Within vCenter, there is a instance ID property that is generated during the installation of vCenter Server which ranges from 0 to 63. This value can manually be adjusted as it is also used to uniquely generate VM Mac Addresses and UUID's as described in this VMware KB.

Here are some additional scenarios in which MoRef ID's will change:

  • Performing a full image restore of a VM when the original VM reference was removed from vCenter (the restored VM will have a new MOR after being registered with vCenter)
  • Restoring a datastore from a snapshot. Although the snapshot is the same datastore, technically it's a new LUN with a unique signature.
  • VMs restored at a DR site, especially when using 3rd party replication tools.
  • Hosts that have been removed from inventory and re-registered with the same vCenter server.
  • restoring a vCenter DB Backup with new VM's after backup taken

Categories // Uncategorized Tags // managed object reference, moref, vSphere

  • « Previous Page
  • 1
  • …
  • 32
  • 33
  • 34
  • 35
  • 36
  • …
  • 40
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025