Quantcast
Channel: virtuallyGhetto
Viewing all 217 articles
Browse latest View live

Automating SSL Certificate Regeneration in VCSA (vCenter Server Appliance)

$
0
0
The VCSA (vCenter Server Appliance) provides a very simple way of regenerating the self-signed SSL Certificate by using the VAMI web management interface. This is extremely useful if you change the IP Address or hostname of your VCSA and want a proper SSL certificate with the correct common name, especially important if you are plan on using something like vCenter Orchestrator which validates this. To regenerate the SSL Certificate, you just need to login to the VAMI web interface by pointing your browser to the following address: https://[VC-IP]:5480 and under the Admin tab there is a option to "Toggle certificate setting".

After enabling this option, you will need to reboot your VCSA for the new SSL certificate to be generated. Once the VCSA is booted up, you will need to go back into the VAMI interface and disable this setting, else another SSL certificate will be generated upon the next reboot.

I was recently asked if it was possible to automate the SSL regeneration via the command-line without using the GUI which would be very useful for automated VCSA deployments. In looking into this, it turns out the process is quite simple and the present of a file within the VCSA will determine whether a certificate regeneration is required.

To enable certificate regeneration, run the following command which will "touch" (create) allow_regeneration file under /etc/vmware-vpx/ssl directory:
touch /etc/vmware-vpx/ssl/allow_regeneration
To disable certificate regeneration, you just need to remove the file after the VCSA has rebooted. Behind the scenes, this is what is happening when you are toggling the option in the VAMI interface and now you can automate this from the CLI without using the GUI!




vOpenData: An Open Virtualization Community Database

$
0
0
Recently, I had the opportunity to help out with a very unique and cool project called vOpenData which was created by Ben Thomas (a former VMware GSS Technical Engineer). The idea for the project was sparked by a very simple tweet that came from Duncan Epping:
Ben wanted to help answer Duncan’s question but more importantly he wanted to help answer a bigger set of questions: what are some of the common virtual infrastructure deployment configurations, averages and consolidation ratios? These questions cross the minds of the everyday vSphere administrators, architects and consultants. It would be quite difficult and nearly impossible to answer these questions outside of their own environment.

Ben reached out to me with his idea and asked if I could help develop a script to collect basic configuration information from a vSphere environment to help test out his idea. I was immediately intrigued with his idea and saw the huge potential value that Ben’s unique solution could bring to the virtualization community. The coolest thing about this project is that we were able to put together a working prototype within a week’s time!

Note: Also be sure to check out Ben's article vOpenData - Crunching everyone's data fun for fun and knowledge and his perspective on how he was able to quickly develop a prototype leveraging a PaaS solution.

What is vOpenData?

vOpenData is an open community project that grew from the question "What is the average VMDK size for deployed virtual machines?” We wanted to create an open community database that is purely driven by users submitting their virtual infrastructure configurations. Leveraging the powerful virtualization community and applying simple analytics we are able to provide various trending statistics and data for virtualized environments. This is 100% community driven and the results will be available for everyone to view and hopefully you will contribute to the overall dataset!

What information do we collect?

We made an effort to not collect specific information such as hostnames or even display names that could be used to identify a particular organization. Instead, we are using UUIDs which are automatically generated by the virtualization platform to uniquely identify a particular object. This allows us to keep track of changes in the our database when a new data set is uploaded from an existing environment. In addition we are collecting various configuration data and you can find a complete list in the Data FAQs

More info on the data we collect is here: Data FAQs

What will this data be used for?

We are planning on using this data to create some interesting statistics and data modeling for the community to use in capacity planning and analysis. Most of this data will be made available through a dashboard or reports and eventually through an API to be mixed into other applications.

What about privacy concerns?

Though the data that is collected is already anonymized and non-identifying, please ensure that you are abiding by the privacy policies of your organization when uploading this data. If you are concerned about the data, it is recommended that you audit the zip contents before uploading which are just CSV files. We only ask that you do not modify the schema at all.

How do to get started?


Step 1 - Check out the sexy vOpenData Public Dashboard here to get a glimpse of some of the information you will find by submitting your configuration data.
Step 2 - Download either the PowerCLI or vSphere SDK for Perl script which you will run against a vCenter Server which will produces a compressed zip file containing several CSV files. Instructions are available on the download page. You may rename the default file name vopendata-stats.zip to something else, as long as you do not modify the contents of the file.

Step 3 - Open a browser and go to http://www.vopendata.org and sign up for new account.

Step 4 - Click on the “Infrastructures” tab at the upper left hand corner. An Infrastructure is a logical view that can help you organize the data you have collected. You can associate a single vCenter Server with an infrastructure or you can combine multiple vCenter Server data sets into a single infrastructure. The choice is really up to you on how you would like to visualize your data and whether you would like to map that to the physical location of your virtual infrastructure.


Step 5 - Once you have created your Infrastructures, you will then upload your data files to their respective Infrastructure. This may take some time as the data processing is executed in the background and will also depend on the number of users and uploads occurring at the moment. We ask that you please be patient and check back in a bit and you can refresh the page which will let you know when the processing is complete
Step 6 - After the data is uploaded to the system, there is a scheduled job that performs the analytics and calculations which occurs in periodic batches. These calculations can take up to 45minutes to an 1hour before the results are reflected in the public dashboard and is primarily governed by the single worker we have on the backend due to resource constraints. To view the results of the public dash board visit http://dash.vopendata.org

We hope you frequent the vOpenData site regularly as the community uploads more and more data and see how statistics are trending over time. We would also like thank the following people who were part of our early alpha program and assisted with both testing as well as code contributions: Frederic Martin, Raphaël SCHITZ, Timo Sugliani and of course my Automation colleague Alan Renouf! If you would like to learn more about the vOpenData project, we have also submitted a session for VMworld 2013 4976 - vOpenData - Crunching Everyone's Data For Fun And Knowledge, be sure to vote for it!

You can follow @vopendata on Twitter for new updates and notifications as well as both Ben Thomas at @wazoo and William Lam at @lamw

How can I help or contribute?

First and foremost, you can get involved by signing up for a free account and begin contributing your data to the open community database! We are also open to any suggestions and feedback as they would be very valuable to us, feel free to join the vOpenData VMTN Community Group to discuss further. We know that in this first release we are not going to be able to show everything, but have plan to show much more. Lastly, all the infrastructure that is used to provide the dashboard, the backend database and processing is all hosted and paid out of our own pockets. If you have found this to be a useful resource and would like to contribute either with a donation or sponsorship to help us continue developing this project, please contact us at vopendata[at]gmail[dot]com

vOpenData Update & FAQs

$
0
0
Ben Thomas and I launched the vOpenData project exactly 1 week ago and we really had no idea what to expect. We were completely blown away with the amount of interest and support from the awesome VMware community! In one weeks time we had contributions from over 30+ countries from around the world and we are approaching 70,000 virtual machines! Below is a quick screenshot on some of the impressive statistics. This has been a huge community effort and we wanted to take a moment to thank everyone who has contributed and thanks to all the bloggers who have written awesome articles to help us get the word out! Let's continue the momentum!


There have been a few requests for showing the top 5 hardware vendors instead of the top 3. To be honest, this was done to have a symmetrical looking dashboard and all the tiles just fitted when we  designed it. We will see if we can adjust a few things to accommodate for this, but I do want to note that Ben is currently on travel for work and modifications to the site may take some time. This also includes the Contributors dashboard which we are hoping to have a prototype in the coming weeks, so please be patient as we work on that.

We have also received many questions and comments about requesting to see certain statistics, ability to filter, what information is collected, etc. and I wanted to put together a quick FAQ to help answer some of these questions for existing vOpenData users as well as new and potential prospects. If there are other things we can help clarify, feel free to leave a comment.

vOpenData FAQs

 

What is vOpenData?

Please take a look at these two blog articles for more details about vOpenData:

What information are you collecting?

You can find the complete list of anonymized data we are collecting in the Data FAQ page here. You can also view the raw contents of the zip file after executing the script. They are just plain CSV files and we highly encourage ever user to take a look before submitting.

What is a vOpenData Infrastructure?

This is just a logical container/view for your data. Once the Contributor's dashboard is available, you will be able to view and filter by various properties within a given vOpenData Infrastructure. This also means that you can either map a single vCenter Server upload to single vOpenData Infrastructure or you can have multiple vCenter Server uploads to a single vOpenData Infrastructure. If you wish to have fine grain filters, it is recommended that you have one vOpenData Infrastructure for each of your vCenter Server.

I still do not see my data reflected in the public dashboard?

It can take some time for both the processing and display of the data after upload. Please be patient and it can take up to an hour depending on the number of users and submissions.

What happens if my vCenter Server environment changes?

As your environment changes, you can periodically run the script and upload your data. If an existing object exists and it has changed, then we will update the record or add a new record if it is new. If there are no changes, then no updates are made.

What browsers are supported for the vOpenData Dashboard?

We are using Dashing for the dashboard application for vOpenData. From their site, it looks like it has only been tested on Chrome, Safari 6+ and Firefox 15+. We have also heard from a few folks that both IE9/10 does not work with the dashboard, so please use one of the supported browsers.

Is vOpenData supported on mobile browsers?

Yes, it should work on all mobile devices including the iPad, iPhone, Nexus, etc.

Can you display statistic X?

The public dashboard is just a tiny percentage of the information we have collected so far. We will provide more statistics as well as methods of filtering when the Contributor's dashboard is released. By looking at the data we currently collect in the Data FAQ page here, you can kind of guess on the types of statistics we will be able to provide.

Difference between vOpenData Public and Contributors Dashboard?

The public dashboard is just an aggregate of all the datasets submitted by the community and it only contains a very tiny percentage of the information we have collected. It is available to everyone and you do not need to sign up to view it. For those who have contributed, there will be a Contributor's dashboard that will be available when it is released and will contain all the statistics we collect. You will also be able to apply various filters on the total aggregated community data as well as your own vOpenData Infrastructures. As you can see, there is a huge benefit to those that submit their data and once the Contributors dashboard is released, you will be able to view all the data in totally new manner.

Can I see specific type of Infrastructure (e.g. server vs VDI)?

This will be available when the Contributor's dashboard is released. 

Is the data submitted mainly lab environments?

Actually, more than 75%+ of the contributed data in the vOpenData database are non-lab environments. This includes Server, VDI, Cloud and Combination environment types. Hopefully we can continue to increase this number even more as we have more contributions from the community.

Why is Windows 2012 not part of the top 10 Operating System or why is Cisco UCS not listed in the top 3 Hardware Vendors/etc?

I was pretty surprised to see these type of questions. The results are all from all the data that has been submitted by the community. If folks feel that this is not correct, then I highly encourage you submit your infrastructures or talk to your customers/clients to submit their infrastructure and let the data speak for itself.

How To Configure vCenter Server 5.0 To Work With VIN 2.0?

$
0
0
Many of you know that I am a huge fan of VIN (vSphere Infrastructure Navigator) and the value it can bring to vSphere administrators and their organizations. With the latest release of VIN 2.0, there are even more exciting features and integration with both the vSphere and vCenter Operations Manager platforms. However, one of the prerequisites for using the latest version of VIN 2.0 is that you will need to be running a vSphere Web Client 5.1 Server which can be a challenge for customers still on vSphere 5.0.

There was a question raised internally awhile back ago on whether it would be possible to have VIN 2.0 function with a vCenter Server 5.0? In the VIN 2.0 release notes, there is a statement that seems to indicate this is possible:
The user interface of the vCenter Infrastructure Navigator 2.0 virtual appliance that is deployed on vCenter Server 5.0 can only be viewed from the vSphere Web Client 5.1
A feature that may not be very well known with the release of vSphere 5.1 is that the vSphere Web Client Server also supports vCenter Server 5.0 which must be manually added through the vSphere Web Client admin application. This means that vSphere administrators not only benefit from all the new feature enhancements of the new vSphere Web Client but will would also be able to get a single view of their entire vSphere 5.x infrastructure.

Given all this information, I suspect this should work and I had an idea on how I could implement this. Since VIN 2.0 can only be used from a 5.1 version of the vSphere Web Client, we can simply deploy a VCSA 5.1 (vCenter Server Appliance) and configure it to point to our vCenter Server 5.0 environment. This will then allow us to use VIN 2.0 with our vCenter Server 5.0 environment while still maintaining our vCenter Server 5.0 environment.

Here is a quick diagram of what this would look like:

For some background here is what the environment looks like:
  • VCSA 5.0 managing ESXi 5.0 hosts with running VMs
  • VCSA 5.1 (configured, but no inventory)
  • VIN 2.0 deployed onto the ESXi 5.0 hosts being managed by the vCenter Server 5.0
Here are the steps to get this working:

Step 1 - Deploy the VCSA 5.1 and configure the system as you would normally. We will only be using the vSphere Web Client from this VCSA.

Step 2 - Register your vCenter Server 5.0 environment using the admin app in the vSphere Web Client. If you are using the VCSA 5.1, you will need to follow the instructions here.
Step 3 - Deploy VIN 2.0 into the vCenter Server 5.0 environment if you have not already.

Step 4 - Open a browser and connect to the VCSA's 5.1 vSphere Web Client. The URL should be https://[VC-IP]:9443/vsphere-client and provide the vCloud Suite License key which is required to license VIN 2.0

Step 5 - Enable discovery for the vCenter Server 5.0 under the "Infrastructure Navigator" tab on the left hand side of the vSphere Web Client.
Step 6 - Once the initial discovery has completed, you should now be able to see VIN information displayed for your virtual machines.

So there you have it! VIN 2.0 functioning with a vCenter Server 5.0 environment with a bit of help from the 5.1 version of the VCSA. You will still be able to connect to the vCenter Server 5.0 environment using either the vSphere C# Client and even the 5.0 vSphere Web Client. Though with so many new features in the new vSphere Web Client, this a great way to start getting comfortable with the new interface and enjoy all the benefits from VIN.

The New vinternals.com (The Y Hacker News Of Virtualization)

$
0
0
vinternals.com was just re-launched today by Stu Radnidge‏(no stranger to the Virtualization community) but instead of a blog as most have come to know that URL, Stu has created something even cooler in my opinion. If you are familiar with how Y Hacker News, Reddit or even sites like Digg work, Stu is basically doing the same thing but for Virtualization-related topics. It is a news website that is completely driven by the community through the submission of either a link or a question. These entries can then be voted on by the community and the top 100 current entries will be displayed on the home page.

I think most will agree that there is already too much information out there today in various forms such as: Blogs, Twitter, Facebook, LinkedIn, Socialcast, Forums, Google+, Email, Distribution Lists, RSS Feeds, etc. and having yet another place to go for information is not going to help. The reason I think this is a pretty neat idea (if successful) for the Virtualization community is that there is a wealth of information out there, why not leverage the community as a whole help surface up useful or interesting content for everyone to benefit?

Many times there are useful bits of information or articles that are not shared through the traditional channels or more often not getting enough visibility before it's lost among the cloud of information. Hopefully with a solution like this, top quality content will be surfaced to the top and significantly help reduce the number of places you need to go for your virtualization-related news.

You will notice the look and feel of vinternals is very similar to Y Hacker News:

The other really neat thing about Stu's site is that there are no passwords to manage. When you sign up, an email with a login link is provided and everything is done using cookies. After you login, you will be able to view the current entries on the home page and if you wish to submit a link or a question, just click on the Submit button at the top.
The input is pretty straight forward: A URL, title for a link or pose a question and click on submit. To vote for an entry, you just click on the green caret icon next to each entry. If you would like to learn more about the new the vinternals site and how it works, you can read about it here

I am looking forward to seeing more entries submitted by the community, Great job Stu! BTW - You need an RSS feed ;)

If you are not signed up, what are you waiting for? Go here to sign up now!

Installing ESXi 5.1 Update 1 on Mac Mini is Now a Breeze! (No Custom ISO/patches Needed!)

$
0
0
ESXi 5.1 Update 1 was just released by VMware and similar to the ESXi 5.0 Update 2 release last year, the tg3 (Broadcom) driver has now been updated to 3.123b.v50.1 which is required to support network connectivity on the Apple Mac Mini's. Prior to this, to install ESXi on an Apple Mac Mini, users were required to build a custom ISO that included the updated tg3 driver and I am happy to say this is no long necessary! In addition, having the latest driver also provides out of the box support for the Thunderbolt ethernet adapter which is great if you are looking to add an additional ethernet connection to the Apple Mac Mini.
Disclaimer: The Apple Mac Mini is not officially supported by VMware.

Here is a quick screenshot of the networking details including the Thunderbolt ethernet adapter on my Apple Mac Mini 5,3 running ESXi 5.1 Update 1:

Note: I no longer have access to an Apple Mac Mini 6,2 and I was not able to confirm whether the issues described here have all been resolved. The workarounds noted in the article may still be required if you are running the latest Apple Mac Mini 6,2

Additional Resources:

Exporting An Amazon EC2 Instance To Run On vSphere

$
0
0
I attended the Silicon Valley VMUG yesterday and there was an interesting question that was brought up at the end of Joe Sarabia's Software Defined Datacenter session (which was great BTW, folks stayed past the end and this was during lunch!). The question from the attendee was how to export an Amazon EC2 Instance and run that on an vSphere ESXi host? Joe's answer was that there is not a tool from VMware but there should be some 3rd party tools out there that could help with this task.

This was not something I had really thought about before since I do not use Amazon EC2 and of course that perked my curiosity. I assumed importing and exporting Instances to and from Amazon EC2 would be just as easy as it is on VMware vSphere. To export a VM in vSphere, you simply select the VM and then Export which can be outputted to either an OVF or OVA format.
After a quick search on Amazon's EC2 website, I found that you can export an EC2 Instance by using EC2 API Tools. So I went ahead and deployed both a Linux and Windows Instance and ran through the installation of the EC2 API Tools on my Mac OS X system at home. I tried to export the Linux Instance and it threw an error saying not supported which I thought was odd and then tried the Windows Instance and it threw another interesting error:
Client.NotExportable: Only imported instances can be exported.
My initial thought was that I must have done something wrong. I dug a bit more into Amazon's documentation which was not very easy to find and finally found the Exporting EC2 Instance documentation. It turns out there are a few "caveats" if you want to export an EC2 Instance:

Only the following operating systems are supported:
  • Windows Server 2003 R2 (Standard, Enterprise, and Datacenter)
  • Windows Server 2008 (Standard, Enterprise, and Datacenter)
  • Windows Server 2008 R2 (Standard, Enterprise, and Datacenter)
This meant that you could not export any of your Linux Instances. In addition, these Instances must be uploaded by the user initially for them to be eligible for export. I also found there were several other export limitations:
  • You cannot export Amazon Elastic Block Store (Amazon EBS) data volumes.
  • You cannot export an instance that has more than one virtual disk.
  • You cannot export an instance that has more than one network interface.
I was actually quite surprised to see how difficult and restrictive Amazon has made it for exporting their EC2 Instances, I really thought it would have been just as easy as it is on VMware vSphere. I also came across this VMware KB 1018015 which provides an alternative to the EC2 API Tools, which has you install VMware Converter on the Windows system to export the EC2 Instance.

How To Enable Nested ESXi Using VXLAN In vSphere & vCloud Director

$
0
0
Recently I had received several inquiries asking on how to configure nested ESXi (Nested Virtualization) to function in a VXLAN environment. I have written several articles in the past on configuring nested ESXi in a regular vSphere and vCloud Director environment, but with the use of a VXLAN backed network, there are a few additional steps that are required. These steps include additional configurations of the vCloud Network & Security Manager (previously known as vShield Manager) which ensures that both the required promiscuous mode and forged transmits are automatically enabled for the VXLAN virtual wires (vWires) as they are managed exclusive by the vCNS Manager.

In this article, I will walk you through the configurations that is required when using VXLAN in both a vSphere only environment as well as a vCloud Director environment. If you would like to learn more about how VXLAN works, be sure to check out the multi-part VXLAN series (Part 1/Part 2) by Venky Deshpande.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

Configurations for VXLAN in vSphere Environment


Step 1 - Deploy vCNS Manager and configure it to point to your vCenter Server (do not enable or prepare VXLAN, this must be done after the configurations)

Step 2 - You will need to identify the VDS MoRef ID in your vCenter Server which will be used in the next step. Since the configuration is applied at the VDS level, you may want to consider having a separate VDS serving Nested Virtualization traffic since both promiscuous mode & forged transmits will automatically be enabled for all vWires. To locate the VDS MoRef ID, login to the vSphere Web Client and select the summary view for the VDS.
The VDS MoRef ID will be towards the end of the URL link and it should start with dvs-X where X is some arbitrary number. Record this value down for the next step

Step 3 - Download the enablePromForVDS.sh shell script which will be used to prepare the VDS within the vCNS Manager. The script basically performs a POST to the REST API to the vCNS Manager using cURL and it accepts three input parameters: vCNS Manager IP Address/Hostname, VDS MoRef ID and VDS MTU. The username/password is hard coded in the script to use the default which is admin/default. If you have modified the default password like any good admin, you will want to change the password before running the script. If you take a look at the request body, you will notice only promiscuous mode is enabled to true, but this will also automatically enable forged transmits as well.

In my lab enviroment, I have the vCNS Manager IP to be 172.30.0.196, VDS MoRef ID to be dvs-13 and VDS MTU to be 9000. So the syntax to run the script would be:
./enablePromForVDS.sh 172.30.0.196 dvs-13 9000
Here is a screenshot of executing the script, you should see a response back with 200 to indicate successful execution of the script.
Step 4 - Now, we will proceed with the VXLAN preparation. Start off by logging into the vCNS Manager and selecting the vSphere Datacenter which you wish to enable VXLAN. On the right you should see a tab called "Network Virtualization" go ahead and click on that and then click on the sub-tab called "Preparation". Click on edit and then select the vSphere Cluster and proceed through the wizard based on your environment configuration.
Step 5 - Once the VXLAN preparation has completed, click on the "Segment ID" and configure that based on your environment.
Step 6 - Next, click on "Network Scopes" and you will create a network scope and specify the set of vSphere Clusters the VXLAN network will span.
Step 7 - Lastly, click on "Networks" and this is where you will create your vWires and ensure it the proper network scope is selected.
Step 8 - To confirm that everything has been configured properly. We now log back into our vSphere Web Client and heading over to the VDS settings page. You should now see a new vWire portgroup that is created, if we take a look at it's settings we should see that both promiscuous mode and forged transmits is enabled.
You are now done with the VXLAN configurations in the vCNS Manager and can proceed to the regular instructions for enabling Nested ESXi for vSphere.

Note: If you have already prepared VXLAN in your environment, you can still configure the above without having to un-prepare your VXLAN configurations. You just need to login to the vCNS Manager via the REST API and perform a DELETE on the VDS switch (Please refer to page 153 of the vCNS API Programming Guide) which will just delete the mapping from vCNS but will not destroy any of your VDS configuration. Once that is done, you will be able to use the script to configure the VDS with the proper settings.

Configurations for VXLAN in vCloud Director Environment 


A VXLAN network pool is automatically created for you when using vCloud Director 5.1, so the steps for preparing Nested Virtualization for vCloud Director is extremely simple compared to the vSphere only environment.

Note: VXLAN is only supported in vCloud Director 5.1, for previous versions you have the choice of using a VCD-NI or vSphere backed network and the configurations for that can be found here.

Step 1 - Please follow the steps 1-5 from above in the vSphere only environment and then you are done. If you would like a more detailed walk through for configuring VXLAN for a vCloud Director environment, check out this article by Rawlinson Rivera who takes you through the process step by step.

Step 2 - Proceed to the regular instructions for enabling Nested ESXi for vCloud Director.

Step 3 - Lastly, you will go through the vCloud Director setup which is to attach your vCenter Server & vCNS Manager, create a Provider VDC, create an Organization and assign resources to your Organization VDC and ensure that the OrgVDC is consuming the VXLAN network pool that is automatically created for you when you create the Provider VDC. Once that is done, when you deploy your vApp, you will see a vWire that automatically created for you. If we login to the vSphere Web Client and go to the VDS settings, you will see the vWire has both promiscuous mode and forged transmits automatically enabled.

Additional Resources:

How To Add A Tag (Log prefix) To Syslog Entries

$
0
0
Last year I wrote an article on how to forward vCenter Server logs to a remote syslog server using the built in syslog-ng client in the VCSA. A few weeks back, I received an interesting email from Michael White sharing details about adding a "tag" or more specifically, adding a string prefix to each syslog entry being forwarded. This was interesting as it enables a user to easily search for a specific log entry based on a "tag" and comes really in handy when you have multiple log sources being forwarded from the same host. An example of this would be the various logs from a vCenter Server such as vpxd, vws, inventoryservice, etc. which all have their own individual logs coming from the same host.

Within the Syslog-ng client configuration, you can specify the log_prefix() option and the string you wish to prefix a given log source. The tag has a specific syntax that must contain a : (colon) and a whitespace after the string (e.g. "VC_APP: ").

Using the vCenter Server as example, we could add the following tags:
After restarting the syslog-ng client for the changes to going into effect, you can head over to your syslog server to view the updated syslog entries. In the screenshot below, we can see we have log sources from both our VC_APP (vpxd.log) and VC_IS (ds.log) entries as specified in our syslog-ng client configurations.


Note: For newer versions of syslog-ng, program_override() is used instead of log_prefix(). The syntax for that would be program_override("VC_APP").

I want to thank Michael for sharing this cool tidbit!

Executing Commands During Boot Up In ESXi 5.1

$
0
0
There maybe certain use cases where you need to execute a command or series of commands during the boot up of an ESX(i) host and historically administrators have added commands to the /etc/rc.local which is one of the last scripts to be executed in the boot up process. However, with ESXi 5.1, the location of the file has changed from /etc/rc.local to /etc/rc.local.d/local.sh.

VMware also provides a KB2043564 that describes the locations for the various version of ESX(i):
  • In ESX 3.x/4.x - You would add the command(s) to /etc/rc.d/rc.local
  • In ESXi 4.x/5.0 - You would add the command(s) to /etc/rc.local
  • In ESXi 5.1 - It has changed to /etc/rc.local.d/local.sh

Disclaimer: As mentioned in the VMware KB, though this is supported, it is still not recommended that you edit these files unless directed by VMware support or under special scenarios.

A question that came up recently was about automatically loading the "multiextent" VMkernel module (which is required if you wish to use the 2gbsparse VMDK format, you can find more details in this blog article here) during the boot up of an ESXi 5.1 host as this had to be done manually, even if you had enabled the module. To do so, you just need to edit the /etc/rc.local.d/local.sh and add the following command above the "exit 0".
localcli system module load -m multiextent
Note: The reason I used localcli versus ESXCLI is that hostd may not be completely ready and hence the command may fail during the boot up process. One can also loop and wait for ESXCLI to be ready, but this is another way of performing the operation.


How To Create Offline Update Repository For VMware Virtual Appliances

$
0
0
Virtual appliances built from VMware Studio provides a very easy mechanism of updating or upgrading the software on the appliance by using the VAMI (Virtual Appliance Management Interface) web interface. The VAMI web interface provides three methods of updating or upgrading an appliance: online update repository hosted by the author of the appliance, CD-ROM or alternate update repository can be specified.
For VMware virtual appliances, a VMware hosted update repository is configured by default and internet connectivity to the configured URL will be required (proxy configurations are supported). However, there are environments where network connectivity to VMware's online repository is just not possible or the update repository must be hosted internally due to security requirements and this is where the third option can be used.

The process to setup your own update repository is not really documented and I have been noticing more requests from customers looking for a way to update or upgrade their VMware virtual appliances without requiring access to VMware's online repository. There are also other virtual appliances such as VCSA (vCenter Server Appliance) which ships both the update contents for an ISO and zip file which can then be used with the two other update/upgrade methods.
Though these files can be generated from VMware Studio as part of the appliance build process, the majority of the VMware virtual appliances do not provide these files for download.

I decided to research this topic a bit and look into building my own offline update repository based on the online update repository from VMware. I figured it should be fairly easy to replicate what is being hosted to a local web server that runs within your own datacenter. After some investigation, I found the  process to be pretty straight forward and only requirement is a web server that can be used to host the contents for update repository. In this example, I will show you how to build an update repository to upgrade VIN (vSphere Infrastructure) 1.2 to 2.0.

Step 1 - Login to the VAMI interface of VIN (https://[VIN-IP]:5480) and under the Update tab and make a note of the the default repository URL.
Step 2 - Download buildVARepo.sh shell script and upload that to a Linux based web server which will automatically build out our update repository.

Step 3 - The script accepts two arguments: default repository URL for a particular virtual appliance (from the previous step) and the name of the directory in which the repository will be created. In this example, I will be using the VIN repository URL and I will name the repository vin:
./buildVARepo.sh http://vapp-updates.vmware.com/vai-catalog/valm/vmw/302ce45f-64cc-4b34-b470-e9408dbbc60d/1.2.0.290.latest vin
The system that the script runs will need to have access to the URL above as it needs to download the required manifest files. Using the manifest files, parses out the package name and downloads the RPM packages to the web server using wget.

Step 4 - The result is a directory structure that will look like the following:
vin/manifest = List of XML manifest and signature files that describes the update and the path to the appliance packages
vin/package-pool = The RPM packages for the appliances for a given update
Depending on the location of where the script was executed, you may need to move it to the proper path in which your web server is configured to serve up content. You should be able to open a browser and point that to the /vin directory and view the contents.
Step 5 - We now log back into the VAMI interface and specify our update repository URL which will be http://[IP-OR-HOSTNMAE]/[REPO-NAME] and save the settings.
Step 6 - Now we head over to the Status sub-tab under Update and click on the "Check Updates" and we should see a new update for our virtual appliance. To update the appliance, we then select "Install Updates" and shortly after we should see our VIN appliance upgrade to 2.0
Note: Not all virtual appliances provide upgrades to the latest versions of the appliance, be sure to check the documentation of each individual appliances to see what is supported. 

Patching VMware Virtual Appliances Using vamicli

$
0
0
Last week I wrote an article about creating offline update repository for VMware virtual appliances and demonstrating the use of the VAMI web interface for updating and upgrading a VMware virtual appliance. However, from an automation perspective, the web interface is probably not the right tool for the job and this where the vamcli can help.
Usage: vamicli [options]
may be:
  network          Network Configuration
  update           Update Management
  version          Version Information
  service          Service Management
Use vamicli to see a list of options.
The vamicli is a command-line tool that is available on all virtual appliances built using VMware Studio and it provides a subset of the functionality of the VAMI web interface. Using the "update" operation, you can check for available updates as well as performing the installation of an update.

To check for the latest update just like you would using the VAMI web interface, you would run the following command:
vamicli update --check
To install the latest update, you would run the following command:
vamicli update --install latest --accepteula
Here is a screenshot example of going through both of these commands on a VIN 1.2 virtual appliance and then upgrading to VIN 2.0:
As you can see the process is pretty straight forward and this allows you to easily automate the updates of your virtual appliances without having to resort to the VAMI web interface.

For those of you who read my previous article and wish to configure a custom update repository without using the VAMI web interface, you can add the following configuration to /opt/vmware/var/lib/vami/update/provider/provider-runtime.xml where value specifies the HTTP address to your update repository as you would configure using the VAMI web interface.

If you would like to configure additional authentication properties such as username and password, then the /opt/vmware/var/lib/vami/update/provider/provider-runtime.xml should look like the following: The password value is encoded using base64, so to generate the encoding you can use the following python snippet (where password is the password you wish to encode:
python -c "import base64; print base64.b64encode('password')"
Note: The configuration changes above go into effect immediately and you can then use vamicli to perform both check and install operations.

VMware Tools For Apple Mac OS X Guests?

$
0
0
With the release of vSphere 5, virtualizing Apple Mac OS X as a guest OS was possible and fully supported from VMware. To do so, you would need to be run ESXi on Apple hardware either the now deprecated Apple XServe 3.1 or an Apple Mac Pro. A comment that came up yesterday on Twitter was that VMware Tools did not exists for Mac OS X guests and this would make it difficult to manage Mac OS X guests on vSphere. I guess it may not be that well known or just an assumption, but VMware Tools does in fact exists for Mac OS X guests and it is also documented in the VMware Tools installation guide.

It is still amazing to me to see the number of guest OSes the vSphere platform supports and perhaps virtualizing Mac OS X is still relatively new for folks and hence the initial assumption about VMware Tools not being available. In any case, I thought I take you through a few screenshots of installing VMware Tools for a Mac OS X 10.7 guests running on my Apple Mac Mini.

In the screenshot below, we can see that VMware Tools is not detected in the guest OS and we have a option to install VMware Tools, so we go ahead and click on that.
This will mount the darwin.iso to the VM from the vmimages directory of the ESXi host and you can proceed with the VMware Tools installation.
Upon finishing the installation, you will be asked to reboot the guest OS and now when we take a look at the VM summary view, we can see VMware Tools is now running in our Mac OS X guests.
Note: For instructions on installing Apple Mac OS X as a guest OS on vSphere, please refer to this tech note.

How To Pronounce Some Of VMware's Acronyms

$
0
0
VMware's announcement last week on the new vCloud Hybrid Services offering generated quite a bit of buzz and excitement. One thing that I had noticed on Twitter during the announcement as well as the days following was discussions around the pronunciation of the vCloud Hydrid Services acronym (vCHS). There were couple of "ways" that folks have heard it pronounced and I thought I write this fun little post and share what the "official" ways of pronouncing some of these acronyms are (at least from my understanding working at VMware)

Disclaimer: I have no comments on us putting little v's on everything ;) 

Below are the top VMware products that I have heard multiple acronyms for and the controversial on how to properly pronounce each of them. I have also provided a link to Google translate which provides a nice text-to-speech (lower right bottom) so you can listen to each of the official pronunciation. If there are other pronunciations that you have heard or any corrections, feel free to leave a comment.

vCloud Hybrid Service (vCHS)

Official:
Other:
  • v-cheese
  • v-c-h-s

vCloud Automation Center (vCAC)

Official:
Other:
  • v-c-a-c
  • v-cac

vCenter Operations Manager (vCOPS)

Official:
Other:
  • v-cops

ESXi Google Authenticator Is Now A VMware Fling!

$
0
0
Earlier this year I wrote an article about using Google's Authenticator application to provide 2-Factor Authentication for connecting to ESXi using either the ESXi Shell locally or remotely over SSH. I also documented the process for compiling and building your own custom ESXi VIB with the help of two VMware engineers (Hongkun Xi & Jian Ouyang). Though the process was not terribly difficult, it did require minor source code modification and building a custom ESXi VIB. This also meant that you were required to lower the security acceptance of your ESXi host to community supported which is not a recommended practice. In addition, the custom ESXi VIB only supported a single administrator account which was root and additional work was required to support multiple administrators.

Well it turns out that both Hongkun and Jian have been quite busy enhancing this project in their spare time and have just released an ESXi Google Authenticator Fling! The Fling is distributed as a custom ESXi VIB which is signed by VMware, so you no longer have to lower the security of your ESXi host. It supports both ESXi 5.0 and 5.1 and it allows for multiple administrators to login using Google Authenticator.

Here is a list of the features that are supported:
  • Two-Factor Authentication for ESXi Shell and SSH access
  • Supports multiple administrators login on esx5.1, and single admin (root) on esx5.0
  • Support for 30-second TOTP codes
  • Support for emergency scratch codes
  • Protection against replay attacks

To learn more about the Fling and instructions on setting up the ESXi Google Authenticator, be sure to visit the VMware Lab's site.

If you have any feedback or questions, be sure to leave a comment on the Fling's web page here.

New Adventures

$
0
0

Today, I will be embarking on a new adventure as I join the VMware R&D Organization as part of the Integration Engineering team. In this new role, I will be working alongside my team to help provide feedback directly to VMware engineering on how we can better integrate and simplify our products both from an operational and architectural standpoint. Needless to say, Automation will play a key role to help ensure that we have the proper interfaces (API/SDK/CLI) to interact with all of VMware’s products and help enable VMware’s vision of the Software-Defined Datacenter (SDDC). In addition, I will also have the opportunity to research and explore new and interesting ways of leveraging VMware products which is something I am very much excited about!

I have been very fortunate to have been part of the Cloud Infrastructure Technical Marketing team here at VMware and had the opportunity to work with some of the most talented folks in the industry. I want to thank all of my Technical Marketing colleagues for all the innovative and fun projects we have collaborated on.

I am very excited for the new opportunity within Integration Engineering and I am looking forward to getting started!

Which Vendor Has A vSphere Web Client Plugin?

$
0
0
It's no secret that going forward, VMware's new vSphere Web Client will be the primary graphical interface for interacting with vSphere and other solutions within the vCloud Suite. This is regardless of whether the interface is using FLEX, HTML5 or some other framework, that is not the the topic of discussion, so please do not ask :)
VMware has also made this very clear in the recent vSphere 5.1 release notes:
In vSphere 5.1, all new vSphere features are available only through the vSphere Web Client. The traditional vSphere Client will continue to operate, supporting the same feature set as vSphere 5.0, but not exposing any of the new features in vSphere 5.1.
vSphere 5.1 and its subsequent update and patch releases are the last releases to include the traditional vSphere Client. Future major releases of VMware vSphere will include only the vSphere Web Client.
The vSphere Web Client was first introduced with the release of vSphere 5.0 with limited virtual machine and host capabilities. In vSphere 5.1, it was completely revamped to bring the large majority of functionality that we have all been used to in the vSphere C# Client and VMware will continue to close this gap and bring other improvements with future releases of vSphere.

As with any major change, this will not happen overnight and will take time for VMware, customers and partners to transition over. Just take a look at the transition from classic ESX to ESXi, it took several years for that to really sink in through the various updates and it is no longer a question or concern anymore.

A common request that I have heard from customers regarding the new vSphere Web Client is the availability of 3rd party vendor plugins. I have found it quite difficult to find all the plugins that are available and I bet customers would love to see a consolidated list in one place that they can search through. Well, I decided to do some research as well as leverage my Twitter followers to help me build out the complete list of vSphere Web Client plugins. I have broken the list by VMware, Partners, Scripted (legacy) and Unreleased vSphere Web Client plugins. I have also tried to include links to each of the 3rd party plugins so you can easily get more information about each of them.

If you are a customer and you do not see a specific vendor plugin, I highly recommend you reach out to your vendor and provide them feedback, this includes VMware. The more feedback our partners receive, the better chance you will get a vSphere Web Client plugin or any other feature for that matter!

If there are other vSphere Web Client plugins that you know of, please leave a comment or reply back on twitter with #webclientplugin and I will update the blog post.

VMware vSphere Web Client Plugins

3rd Party Vendor vSphere Web Client Plugins

Scripted vSphere Web Client Plugins (not "native" plugins but legacy C# Scripted method)

Unreleased vSphere Web Client Plugins

If you are interested in learning more about the new vSphere Web Client including videos and demos or looking to develop your own vSphere Web Client, please take a look at the additional resources below.

Charlotte VMUG vOpenData Presentation Posted + New Stats

$
0
0
Last week I had the privilege to attend the Carolina Users Summit and from what I hear, it is one of the larger VMUGs in the US. I was asked to give a presentation on a recent community project that I collaborated with Ben Thomas on called vOpenData. The presentation goes into some background on the how the project got started, a deeper look at how it works and a live demo including some interesting stats that have not been shared before (CLTVMUG exclusive!).

I would like to thank everyone who attended the session and the great questions that were brought up. For those of you who missed it or could not attend, I have posted the presentation online and you can download it here. I hope everyone enjoyed it and hopefully you will contribute your data as well as help spread the word about vOpenData! Both Ben and I have been quite swamped with work and changes lately, so hopefully we will have some a nice update for everyone real soon!

Even if you know what vOpenData is, I think it is still worthwhile to check out the presentation as it contains a bunch more stats that have never been shared before. Here is a sneak peak of two that I am sure both Duncan Epping and Frank Denneman would be quite proud of:

Clusters w/vSphere HA Configured:

Clusters w/vSphere DRS Configured:

Lastly, I would like to give a big thanks Charlie Gautreaux for inviting me out to the Charlotte VMUG! I had a great time and met a lot of really cool people!

Configuring vSphere Infrastructure Navigator (VIN) To Manage An Alternate vCenter Server

$
0
0
When deploying vSphere Infrastructure Navigator (VIN), it is automatically associated with the vCenter Server from which it was deployed from and this behavior is by design. This means if you have two vCenter Servers, you will need to deploy two separate VIN instances, one for each vCenter Server as shown in the diagram below.
For scenarios where you have a separate management and compute cluster, each with their own vCenter Server, it can pose a problem if you want to run all your "infrastructure" virtual machines in the management cluster and not in the compute cluster. This very topic was recently brought up in an internal discussion and after explaining how VIN works, I safely assumed this behavior could not be modified. It turns out the discussion peaked the interest of one of the VIN developers and a suggestion was made on how one could potentially change this behavior. This un-tested (NotSupported) "workaround" would allow a user to deploy a single VIN instance under the management cluster and allow it to associate with another vCenter Server and its workloads. Below is a diagram on what this would look like.
Disclaimer: This is not officially supported by VMware, use at your own risk.

There was also one major issue with the workaround which was the changes would not be persisted after a reboot of the VIN instance, which meant you had to repeat the series of steps each time you needed to reboot VIN. After doing a bit of research and testing, I came up with a solution in which the changes will automatically be applied to ensure they are persisted upon each reboot. Basically we are going to do is deploy a VIN instance on each vCenter Server and initially and only configure the VIN instance in the compute vCenter Server which you wish to monitor. Once that is configured, we will then copy a few configuration properties and transfer that to over to our management vCenter Server.

Step 1 - Deploy and configure a VIN instance as you normally would to the vCenter Server in which you wish to manage. From my testing, you will also need to ensure you enable discovery using the vSphere Web Client before proceeding to the next step.

Step 2 - Login to the VIN instance via SSH and we will need to collect a few pieces of information from /opt/vmware/etc/vami/ovfEnv.xml which contains the vService Extension information for the VIN instance. You will need to record the following pieces of information from the file:
  • evs:URL
  • evs:Token
  • evs:X509Thumbprint
  • evs:IP
  • evs:Address

Step 3 - Download the updateVINvCenterServer.sh script and update it with the information you have collected in step 2. Once this is done, you can now power off the VIN instance you just deployed (we will delete this instance later).

Step 4 - Deploy another VIN instance into the management vCenter Server. Once the VIN instance has network connectivity, go ahead and scp the modified script to it. Login to the VIN instance via SSH and execute the script by running the following command: ./updateVINvCenterServer.sh This will take the information that was collected and update its ovfEnv.xml. Lastly, you will need to restart the VIN engine for the changes to go into effect by running the following command: /etc/init.d/vadm-engine restart
Step 5 - Login to your compute vCenter Server via the vSphere Web Client and re-enable discovery under the vSphere Infrastructure Navigator tab. You are now actually talking to the VIN instance running in your management vCenter Server!
Step 6- Shortly after the discovery process has started, you should now be able to see VIN information for the virtual machines residing under your compute vCenter Server without having to actually run VIN under that same vCenter Server. At this point, you can delete the VIN instance located in your compute vCenter Server.

Step 7 - This very last step is needed to ensure the configurations are persisted upon a reboot as the ovfEnv.xml is dynamically regenerated upon each reboot. To do so, we just need to create a simple boot script that executes the script as well as restarts the VIN engine. We normally would add the commands under /etc/rc.local but since VIN is SLES based, that file does not exists. However, you can create /etc/init.d/after.local (which will execute commands after the initial init scripts) and add the following two commands:
/root/updateVINvCenterServer.sh
/etc/init.d/vadm-engine restart
Using this solution, you can now run multiple VIN instances and have them manage separate vCenter Servers all while running under a single vCenter Server compute cluster. Below is a diagram of what that would look like as well as a screenshot of the environment I have setup in my lab. Though this solution is not officially supported, I have seen a few folks ask for this functionality within VIN. Do you think this is something VIN should support and allow it to be decoupled from the vCenter Server  it is deployed from? If so, please leave a comment or if you have additional feedback on this which will help engineering decide whether this is something they should look into.


All the credit goes to to Boris Serebro, the VIN developer who suggested this neat workaround. Thanks for sharing!

Can You Backup & Restore Apple Mac OS X Guests Using vSphere Data Protection (VDP)?

$
0
0
It is really cool to see more and more customers show interest in running Apple Mac OS X on vSphere. Just the other day there was another interesting question that was raised from a customer asking whether vSphere Data Protection (VDP) would be able to backup and restore Mac OS X guests.  Apparently there is still an assumption that VMware Tools do not exist for Mac OS X guests? Perhaps virtualizing Mac OS X is still relatively new for some folks, but it is just like any other guest operating system that is supported on vSphere.

I think the following two statements should help clarify any confusion that may exist:
  • To virtualize an Apple Mac OS X guest, you need to be running vSphere on Apple hardware. This is due to a requirement in Apple's EULA and is also enforced within the vSphere platform. You can get more details in this article
  • VMware Tools does exist for Apple Mac OS X guests, take a look at this article for more details.
Now, if we take a look at VDP's evaluation guide on page 4 we will see the prerequisite for backing up a guest OS is pretty straight forward:
At least one virtual machine running a supported guest operating system (OS) with VMware Tools installed
Since Apple Mac OS X (10.8, 10.7, 10.6 and 10.5) is a supported guest operating system and we have VMware Tools for this operating system, then yes VDP can be used to backup and restore an Apple Mac OS X guest. To demonstrate that this actually works, I have a Mac OS X 10.7 VM running in my home lab (Apple Mac Mini which is not officially supported) and I have deployed the latest version of VDP.
I then setup the backup job for the Mac OS X guests using the super simple VDP backup wizard and then initiate a backup.
Now, let's say I accidentally fat fingered an operation and deleted this VM. Uh oh!? What am I to do? Well don't worry, VDP is there to the rescue!
To restore the VM, it is simply going through the VDP restore wizard and in just a few minutes, I  have now recovered my Mac OS X guest and it is up and running again!
I have said this many times, but it still amazes me on the number of guest operating systems vSphere supports! There really is no workload that vSphere can not virtualize! So if you have any use cases for Mac OS X workloads, rest assure you can safely virtualize it and back it up on vSphere.

Note: Though I showed using VMware VDP as the backup/recovery solution, you should also be able to leverage both VMware vSphere Replication as well as VMware Site Recovery Manager.
number of guest OSes the vSphere platform supports
Viewing all 217 articles
Browse latest View live