This is a continuation of the VMware vCloud Usage Meter 220.127.116.11 – End to End Deployment and Configuration (1 of 3)
Post 1 of 3 here
vCloud Usage Meter Web Configuration
- Now we are ready to log into the Usage Meter from your browser. Google Chrome is the best choice for Usage Meter.
- Point your browser to https://<UM-FQDN>:8433/um
- Accept the self-signed cert and continue to the login page. Type admin as your username and the password you set when we set the webpass password.
- Accept the Terms and Conditions.
- Before we start doing any product configuration, we need to set up the Provider and Email information.
- Under the Provider tab, put in the Company/SP Name, contact email address (I usually put in the person who is responsible for UM collection), and your Partner ID and Customer Number. Site ID is for you at this time – we may use for this for future versions on multiple UM instances. Press Save when complete and it should bring you to the Email tab. Note: If you are installing Usage Meter for initial data collection and/or proposal purposes, you can put in “1234567” or “99999” for the Partner ID/Contract Number.
- On the Email tab, put in your SMTP server FQDN or IP address. If it’s an open relay, it will not need a username/password. Authentication options are available.
- Now press the Send email button – this will send a test email to VMware along with the individual email address you supplied on the Provider tab. If it is successful, you will receive a successful message along with an email to the specified address. As shown in the 2nd screenshot below, I can see that I received a successful test email.
- Now press the Save button – from here, it will immediately bring you to the Products page.
vCenter and vRealize Operations Setup
- Now we are ready to add our VMware management systems. First, let’s add our vCenter. Click the Add button right below the vCenter Server category. Do you have an external Platform Services Controller? If so, make sure you check the box and input the required info! If you are using SRM, this dropdown will be available once the secondary vCenter site is connected. When finished, press Save
- OK, we can now see a message showing UM attempting to log into vCenter. If you get errors on this part, there are two possibilities: 1) wrong credentials or 2) ports are not open.
- Great – we can now see a message requesting us to accept the certificates. Press Accept All.
- Alright, vCenter is now showing on our list and now we see vROps was automatically detected. This is done by the MOB extension list inside of vCenter. Press Accept All to accept the certificate. The wrong vROps instance showing here? Here’s how to fix it.
- Now we can see vROps in the list, but we need to update the credentials for it to activate. My vROps instance is not connected to the SSO domain, so I am going to use local admin credentials. Press the Edit button by the vROps instance and put in the credentials.
- Now we can see a message stating vROps credentials are correct. Excellent. It will still show Not Yet Discovered until the next hourly collection interval – do not worry. Do check it in an hour to verify the message has been removed.
- We are now complete for vCenter and vROps! If you have any other instances of vCenter, please repeat these steps. vROps cannot be added independently – it must be tied to a vCenter instance.
NSX Manager Setup
- Now let’s add the NSX Manager instance. Very straightforward – hit the Add button under the NSX Manager section. Now we need to input our NSX Manager FQDN or IP, username and password (remember, NSX Manager instance credentials!) along with the connected vCenter server.
- A similar message we saw from vCenter additions – accept the certificate and hit Accept All.
- We will see a testing credentials message and once that disappears, NSX Manager will populate in the list. Done! Repeat these steps for any additional NSX Managers.
vCloud Director Setup
- Again, very similiar steps for vCD integration – the key difference is you do need sysadmin privileges to access vCD from UM.
- Click Add under the vCloud Director section and input the FQDN/IP along with the credentials.
- We will see the message to accept the certificate again – hit Accept All. Once that happens, it will test the credentials and populate into the list. Done!
Now, we will go ahead and set up and review Usage Meter Reporting.
At VMware, I get a lot of questions regarding the best way to install vCloud Usage Meter for a successful setup. This post will highlight the key points I’ve learned in my time working with the product. In a future post, I will detail how to use Usage Meter for estimating vRAM / points usage.
This Usage Meter review will be broken out into the following sections – I have split this into three posts.
- Key Requirements for Usage Meter
- vCloud Usage Meter Initial Configuration
- vCloud Usage Meter Web Configuration – Starts on Part 2
- vCenter and vROps Setup
- NSX Manager Setup
- vCloud Director Setup
- Verifying and Configuring vCloud Usage Meter Data Collection – Starts on Part 3
- Customer/Rules Setup and Walkthrough
- Monthly Report Walkthrough
- Monthly Report Collection
Key Requirements for Usage Meter
- Ensure the network ports are open! Network/firewall rules are the #1 item that goes awry with a Usage Meter setup.
- Key Port: 443 TCP – this is used for Usage Meter -> vCenter/NSX/vCD/vROps – ensure this is open!
- 8443 TCP is needed inbound to access Usage Meter
- 443 and/or 25 outbound for SMTP emailing is required from Usage Meter
- All ports are in more detail here – vCloud Usage Meter TCP Port Configuration
- Appliance Size: 2vCPU / 3.6GB Memory / 60GB VMDK
- Create a fully qualified domain name and register the IP with your DNS server – just makes things easier.
- Have your service accounts created for the products that need to be monitored.
- vCenter – global read-only access (created at the top level)
- NSX Manager – read-only administrative privileges
- vCloud Director – system admin privileges
- vRealize Automation – read-only administrative privileges
- vROps – automatically discovered
- Create a Network Protocol Profile for the OVF deployment. This is a commonly missed step and barks about no network pools available.
- To set this up, browse to your Data Center -> Manage -> Network Protocol Profiles
- Create a new profile (or reuse one) and name it while setting what network(s) Usage Meter will sit on
- Under Configure IPv4 – set your subnet/CIDR, default gateway, and DNS server. I know this sounds counterintuitive, but you do not need to enable the IP Pool for manual/static configurations. I typically do not bother with IPv6.
- Under Set other network configurations, I usually set the DNS domain and search path.
- Deploy Usage Meter where it’s readily accessible to the monitored environments. For Providers, it usually makes sense to deploy this a management cluster that has access to resource vCenters.
vCloud Usage Meter Deployment Steps
- Download vCloud Usage Meter – https://my.vmware.com/en/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vcloud_usage_meter/3_6
- OK – before we start to deploy the OVA file, did you remember to establish your Network Protocol Profile???
- Let’s go ahead and deploy it to my Management Cluster –
- Click Next and ensure we see vCloud Usage Meter 18.104.22.168 –
- Accept the EULA
- Provide the VM name and folder location
- Select your datastore
- Network setup – select the network you put in the Network Protocol Profile and select your IP Allocation method. I typically do static since I have a DNS entry established.
- The final step for initial deployment – now we need to provide the root and usgmtr passwords along with the IP address of the Usage Meter appliance. Make sure you remember these passwords!
- Verify everything looks good and press that Finish button…
Excellent! Now we should see vCenter deploying and creating the new Usage Meter appliance.
It will take about five minutes for it to fully initialize and start to be available on the network.
vCloud Usage Meter Initial Configuration
- Open up the console and ensure the FQDN/IP is available from your workspace.
- Now let’s hop into the console – we are going to do two things: 1) Set the timezone and 2) set the admin account to log into the web console – this is COMPLETELY separate from the root and usgmtr accounts.
- Setting timezone – click into the console and press the arrow down button to select Set Timezone
- Select your appropriate continent, country, and timezone. Then confirm the changes.
- You will then see a message stating timezone settings have been changed and now back to the blue screen. Let’s now login –
- Press enter and type in root and the password that you set at deployment.
- Now type in “webpass” without the quotations. Now type in the password you would like to set for the admin account when we log into the web interface.
- OK! One last thing – for some reason, my hostname did not set correctly when deploying. I see localhost when it should be usage361. Let’s use this as a teachable moment when something goes awry on the network side.
- Type in “/opt/vmware/share/vami/vami_config_net” – this is a script we use for Usage Meter network changes to this appliance. From here, you can update the IP address, hostname, DNS, etc. DO NOT use traditional Linux commands to update network values – use this script as this updates both the system and Tomcat configurations.
- Alright, selecting choice 3 and typing in the correct FQDN. For a hostname change, this does require a reboot – so I’m going to press 1 to exit and reboot Usage Meter.
- After the reboot, my hostname is correct.
Next, we will go over the vCloud Usage Meter Web Configuration.
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.