First off, I should have had this drafted before I hit VMworld – big mistake! Cannot underestimate the amount of time that is spent here.
I’m very excited to discuss the announcement of vCD 9 – we’ve been beta testing this with a select group of providers and have been getting some great feedback.
Formal announcement here: https://blogs.vmware.com/vcloud/2017/08/vmware-announces-new-vcloud-director-9-0.html
Key areas I’d like to highlight:
- Tenant UI is now all HTML5. This is great as if it follows our new approach to H5 and provides the ability for providers to customize. We will continue to release new skins as time progresses.
- NOTE: part of the engine overhaul also separates the UI from the vCD process. Therefore, we will be able to make UI changes without disrupting the vCD backend daemon.
- Extender – I’ll have more on this soon, but we have a new plugin to move workloads from the tenant on-prem infrastructure to vCD cloud environment: cold or warm. This plugin will be at no additional cost to our Cloud Provider Partners.
- Validated Stack – our BU will now publish a certification matrix on what versions of code have been validated for vCD. This will take the guesswork out of upgrades and deployments – saving you time!
Again, more to come but very excited about vCD 9. #longlivevCD
I recently did a blog on the Management Pack for vCD on vROps – great way of a vCD admin to manage their vCD solution.
VMware just released the vRealize Operation Tenant App for vCloud Director 1.0 – this now allows you to provide tenant access to their org/VDC and provide tenant-level metrics! Very excited about this.
- Tenant Admin specific views to enable Operations Management solving monitoring, troubleshooting and capacity planning use cases
- Provider Admin can pick and choose the tenants to whom access it to be provided
- Photon OS based Virtual appliance (OVA) for easier installation
- HTML5 Client based on VMWare Clarity
Get it here: https://marketplace.vmware.com/vsx/solutions/management-pack-for-vcloud-director
I’ll be updating this post with things I learn about 3.6 as time progresses.
Change IP / Gateway / Hostname / DNS / Proxy Server
- This *could* be done within your standard Linux commands, however, Tomcat is running in the background and does require manipulations also.
- The recommended process is using a bash shell script named “vami_config_net” – this is under /opt/vmware/share/vami/
- Run the script from your console to get the menu:
- Pretty self-explanatory on what it requires after you select a sub-menu.
SSH and Root Logins
- SSHD is not started by default nor can you log in with the root credentials. IF it is required (by VMware Support), this is the process on enabling access.
- To enable root, edit /etc/ssh/sshd_config and look for line “PermitRootLogin” – change this from no to yes
- Then start (or restart) the sshd service – “service sshd restart/start”
- NOTE – This should be a TEMPORARY solution if you need to access the shell via root. Follow all security practices when possible!
Root account locked
- Yeah, don’t ask how I did this – but had to figure out the procedure on unlocking the root account.
- Simple instructions here on getting into the bash shell from GRUB – https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147190
- From there, you’ll need to use the “pam_tally2” command to reset the lock on the root account.
- So… “pam_tally2 –user=root –reset”
- Ensure your path is set if it errors out: “export PATH=”/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin”
December 20th Update – this procedure works for upgrades to the newest version of Usage Meter 3.6.1. The migration process remains the same.
With our new release of vCloud Usage Meter 3.6, I have several SP’s requesting the work effort for migrating from 3.5 to 3.6 Usage Meter. I am doing this in my lab environment and showing the steps required for the data migration.
Official Instructions: https://docs.vmware.com/en/vCloud-Usage-Meter/3.6/com.vmware.vcum.usersguide.doc/GUID-88DD4D6B-B357-46D5-A6B7-AC1EDB7F423E.html
- Usage Meter 3.6 appliance stood up and IP’d – you do not need to point it to your Products (migration tool will take care of that)
- Snapshot BOTH UM appliances
- SSH turned on both 3.5 and 3.6 appliances.
- Timezone is the SAME on both appliances
- Under Manage -> Provider, ensure the Contract, Phone, Partner ID, Contract Number, and Site ID MATCH
- SSH to both appliances as “usgmtr” – NOT root – this is to test to ensure I can log in successfully to both Usage Meter appliances.
- Run “migrateum <hostname-of-UM3.5>” on the new Usage Meter appliance.
- And if you forgot to SSH as the usgmtr account, you’ll get this!! 🙂
- OK, SSH now as usgmtr on the 3.6 appliance – running “migrateum usage35.corp.local”
- IF you met the pre-reqs above, you should get a confirmation screen like this:
- After confirming, you should see the copy operation start. I didn’t have much data on my UM instance, so this was pretty quick.
- Let’s log into the 3.6 instance….
- You’ll get the confirmation page again to accept the terms:
- Accept the certificate for any product (I had vROps pop up):
- vCD was not showing up for me also – I had to check the box “Show inactive” and Activate:
- What’s great is all of my Customers and Rules moved over…
- And previous Report data is there!
Once you verify everything looks good, DON’T FORGET TO REMOVE YOUR SNAPSHOTS!!!
Not a very tough migration – just ensure your 3.6 UM is configured exactly the same way as the 3.5 instance or the migration tool will error out.