• • Org Name
  • New Org Network Name
  • OrgVDC
  • Edge Gateway
  • IP Information (Gateway, Subnet, DNS, IP Ranges)

Here is the information I used for my test:

• • Org Name: 1001
  • New Org Network Name:  1001-Test
  • OrgVDC:  (This is generated in the script for me based on OrgName.)
  • Edge Gateway: (This is generated for me via Search-Cloud and based on OrgName.)
  • IP Information:  Gateway – 192.168.2.1, Netmask: 255.255.255.0, DNS: 192.168.2.1
  • IP Range Information:  192.168.2.100-192.168.2.200

There are a couple of things that you need to step through to gather the data and I won’t go into details of it in this post due to time. There are quite a few good examples to follow out there but nothing specific to creation of natRouted or direct OrgNetworks.  One that I found very useful was Jake Robinson‘s post regarding vApp Network creation with PowerCLI, Deepdive: vCloud vApp Networks.  This post led me to a good starting point along with a tad more help from him on the VMware vCloud Director PowerCLI VMTN Community Forums.

Before this gets too long winded for the time I have, here is the script:

Anyway, I hope this helps you figure out what you need to do to get OrgNetworks created in vCD 5.1 now.  I didn’t want to go into too much detail because I have heard from a little birdie that there is going to be a deepdive about OrgNetworks on a certain good blog (Geek After Five), so keep your eyes peeled for that.  Also, for a good reference of the Cloud Views since it isn’t well documented, take a look at the vCloud API Schema Reference.  Now back to work for me…

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

Bilal Hashmi (cloud-buddy.com) and I will be presenting Session ID 4873, vCenter: The Unsung Hero, where we will dive into the importance of the availability of vCenter and how it affects the services around it that tie into it.  We will touch on some best practices and other solutions to aid in building a resilient vCenter.

Dan Mitchell (vCO Sr. Product Manager) and I will be presenting Session ID 5703, Supercharging vSphere Web Client with vCenter Orchestrator (vCO), where we will dive into how to extend the functionality of the vSphere Web Client with the awesome-sauce of vCO.

Lastly, I will also be presenting Session ID 4875, vCenter Orchestrator: A Beginner’s Guide, where I will embark on the journey of what vCO is and how you can use it to extend your cloud automation and orchestration.  I will be taking the stance of presenting in a manner that will bring light to anyone who is new to vCO!

Here is a screen of the sessions:

If you are interested and want to learn some cool stuff then go vote for the sessions, it would be greatly appreciated!  You can vote by going to VMworld 2013 Public Voting and clicking on the “Thumbs Up” icon by the session name.  Be sure to filter by either Session ID or my name to get the above list.  There are quite a few awesome sessions this year and hopefully, with your help, I will bring some of that awesomeness to the table!

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

In order to use the tool, you must have the following:

Administrative privileges on the server(s) you are running the tool on. Although non-administrator users can download and launch the tool, all operations will fail without the proper permissions.

• Access to each server that has vSphere components for which the SSL certificate will be updated.
• All vCenter Server components which will have their certificates updated have already been installed and are running.
• The new certificates already exist and you know the location of the new certificates. For increased security, generate each certificate and private key on the machine where it will be used. The new SSL certificate for each vSphere component must have a unique base DN.

So you don’t have to go around looking, here is a couple of links to KB articles on how to use the vCenter Certificate Automation Tool:

• Generating certificates for use with the VMware SSL Certificate Automation Tool
• Deploying and Using the SSL Certificate Automation Tool

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

Figured I would throw this up here for fun…

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

And in hostd.log I saw this:

It is obvious through those errors what the issue is.  Once you come to that conclusion you will need to do some checking around.  The first thing I did was look in /tmp.  Low and behold my ls -l command showed me an ever scrolling list of current.png[1-9]*.  Thousands upon thousands of these were there.  For those of you not aware of what these are, they are the screencaps you would see in the vCloud Director Portal of your VMs.  The first thing one would think to try is to remove all of these with “rm -f current.png*”.  WHOOPS!  That won’t work in this case because the “argument list is too long”.  The way to get around this error is to do one of the following:

or

This will remove the current.png files, releasing the inodes.  If you watch the logs (hostd, vmkernel) you will see that everything starts to process again.  After a few minutes it will reconnect to vCenter again.  Enjoy!

UPDATE: After I did some research on this I found that there is a KB Article regarding this (KB #2031839).

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

Ok, sorry for yelling but I can’t stress this enough!  Make sure you have a backup of your vCD database before doing anything related to modifying the database directly.  Here are some, what I consider, best practice tips for doing vCD database work:

• Quiesce all the vCD cells
  • Shutdown the vCD cells
  • Backup the vCD database

Once you have completed the above steps open your favorite database UI or go straight to the command line.  I will not go into the specifics on how to do this as I just don’t want to have that on my conscience if you mess something up!  When you are in the database you will want to find the VM in the vCD VM table.  You can search for it using the UUID from the error in the vCD interface.  You will notice that the row reports that the status is DELETING_CONTENTS.  You will want to change this to have a status of RESOLVED.

Next, we need to find the vApp in the VM_CONTAINER table in the vCD database.  You can follow the same steps as above to find it by using the UUID of the vApp, which you can grab from the error as well.  Once found, you will see that it shows a status of DELETING_CONTENTS as well.  This will need to be modified to RESOLVED.  When you have completed this and committed the changes you need to refresh your view in the vCD interface.  You will see that the status is no longer Pending.  Go into the vApp and you will probably see the VM is Partially Powered Off.  Go ahead and right-click the VM and Power Off.  It should power off clean now.  Go to the vApp and shut the vApp down, this to should complete successfully.  Finally, go ahead and right-click the vApp and delete!

Yay!  If things worked out for you then awesome…if not, please open a case with VMware regarding your issue.  As stated in the disclaimer, be careful with this and remember that your mileage will vary!  Hope this helps!

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

Knowing the short answer was easy, but explaining how it could be done now with SSO without “linked-mode” spawned a test in my home lab.  The test is to have more than one vCenter Server Appliance (VCSA) attached and manageable through the 5.1 vSphere Web Client.  In short, the answer is yes, it can be done.  Here is how:

You will first need to deploy another VCSA somewhere, in my case it was in my lab where my other VCSA was deployed.  Once the deployment of the OVF is done you will want to login to the VAMI by going to https://:5480.  Your initial login is, of course, root and the password is vmware.

Once logged in you will be presented with the setup wizard.  Accept the wonderful EULA then select custom configuration.

Set your database to either Oracle or embedded based on your design.  When presented with the SSO settings select external and enter the corresponding information as requested.

Make sure that you check the Trust SHA-1 thumbprint or the registration of the VCSA with your other VCSA/VC will fail.

Reboot the new VCSA, once all of the services start up you will be able to manage this in the vSphere Web Client…well, at least if you login as root into the webUI.  How do you fix this?  Easy, the same way you adjust permissions within vCenter.  Login to the webUI as root and go to the vCenter Inventory List where you will see all of the vCenter Servers.  Select the one you just added and click on Manage in the main screen…set permissions for your ESX Admins group or whatever group you may use…VIOLA!  You now have the ability to manage multi-site vCenter Server Appliances.  AWESOME!

Hopefully this helps you set this up and if you have any questions/comments/concerns/rants then please feel free to post them in the comments!

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

So like many others I deployed vCloud Suite 5.1 into my home lab…all things were perfect until I decided to play with vCD and SSO.  SSO has had quite a stream of people complaining about it and also those saying how great it is.  As of right now, my personal take on it is that I am indifferent.  Anyway, that is not the point of this quick post…the point is:

So I was receiving a crazy 500 error after attempting login through the vSphere Web Client to vCD.  For those of you not in the know about how to do this, check out the vCloud Director Admin Guide on page 127, “Configure vCloud Director to use vCenter Single Sign On“.  Anywho, after attempting the configuration, which mind you is relatively simple, I somehow managed to bork the configuration.  This resulted in a 500 Internal Server Error exclaiming: Incoming SAML message is invalid.  One would think, “No worries, I will just disable SAML/SSO in the administration portal.”

After a cry for help on Twitter late at night with nobody to respond, I decided this morning to dig into the Oracle database.  While looking through I see a table called IDENTITY_PROVIDER…looks like I may have found a place to disable the SAML/SSO authentication method.  VIOLA!  I did find it!  Now to change it…to do you will want to:

1. Make sure you have a backup of your database.  (I did this in my lab!  Use at your own risk on ANY environment!)
2. Connect to the Oracle DB.
3. Run the following SQL: UPDATE VCLOUD.IDENTITY_PROVIDER SET IS_ENABLED = 0 WHERE PROVIDER_TYPE = ‘SAML’;
4. Attempt to log back into vCD.

If all goes well, you should be back into vCD!  If you go to Administration->Federation you should see that Use vSphere Single Sign-On is no longer checked!  I am not sure that this is the proper method but it worked for me and I have not had any weird issues since making the change.  Hope this helps!

UPDATE:  Thanks to Luke (@ThepHuck) for doing this on Microsoft SQL.  Here is the script:

UPDATE:  Thanks to Mathew Lodge (@mathewlodge) you can just add login.jsp to the URL to gain local login access like so:  http://vcloud.vsential.lab/cloud/login.jsp

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

This document will also be included in the updated AutoLab documentation soon.  Hope this helps everyone out!  If you have any issues then please sound off in the comments or hit me up on Twitter.

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.

1. Open up Terminal.
2. Do the following:  cd /Library/Preferences/VMware Fusion
3. You will want to edit the file called “networking”.  So:  vi networking
4. Find the IP that UBER Network Fuser has chosen in this file for VMnet3 and change it to reflect 192.168.199.0.
   

   Screenshot of the networking file and what to look for.

5. Save the file.

Are we done?  Nope…one more quick thing before I let you go.  I found that when bringing the AutoLab VMs into Fusion one will want to copy them to their Virtual Machines folder and then rename the VM’s folder to <VMname>.vmwarevm.  This will allow UBER Network Fuser to see the VMs so you can adjust the custom networks as needed.  Now after this has been completed, you should be able to continue through the AutoLab documentation and start placing the content needed on the NAS VM.  if you have any questions then please feel free to ask in the comments.  I will continue to post more as needed as I get this configured on my MBP.

This article was originally posted on vSential - virtualization in the real world. Visit the site for more information on virtualization and related technologies.