Wednesday, June 24, 2015

VMware and the Leap Second




What is Leap Second ?
Nowadays do you even remember that Earth’s rotation around it’s own axis determines the length of a day or 24 hours (close enough) ?!?!

The thing is, Earth’s rotation is slowing down, very slowly, that means the leght of a day is not a precise 24 hours. Since we use Atomic clocks to synchronize time around electronic devices and those Atomic clocks are damn accurates, from time to time there's  a difference between them. When this difference approaches 0.9 seconds a +1 second is added to UTC, last time it occurred was on June 30, 2012.

So on Jun 30, 2015 23:59:60 UTC a leap second will be added.

Pay attention: It will be added at UTC time zone, if you are on a different zone, the change will occurs at another time of the day, example: on EST it will occur at 19:59:60.

Now that you understand what Leap Second is, let’s see how it does impact VMware’s products.

First and most important, it will only, potentially, affect systems that are configured to receive time synchronization from NTP server, so I assume everything is affected.
If you are not using NTP for synchronization, start remediating it NOW.

Second, it depends of how the operational system handles the Leap Second adjustment and each one will handle that differently.

There’s a common sense that you should change your NTP to slew mode, which will not make huge adjustments on it’s own time and will compensate the Leap Second progressively.

VMware’s has created a KB2115818 with all affected systems and how you address it on every one of them.

Also there’s a KB2121624 which shows systems not affected by the Adjustment.

Here's a link If you are interested on learn more on Leap Second.

And if you are wondering if it still make sense measuring our time based on Earth’s rotations here’s another one.





Tuesday, June 16, 2015

Generate Internal Certificate for vRealize Log Insight


This post is another contribution of one of my friends, he's a VMware's Technical Account Manager, in fact he’s the oldest VMware’s TAM in Brazil, combining deep expertise and business oriented approach, he has been helping dozens of clients to extract the most of their VMware's products while bring to them all the innovation VMware has to offer, please, meet Jean Oliveira.

One of Jean’s clients wanted to replace vRealize Log Insight self-signed certificate with an certificate provided by an internal Microsoft CA.
Despite the fact you find the details on the documentation, he found a little bit more of information was required, so he created this procedure to avoid  keep jumping back and forward for information.


**** Create a Certificate Signing Request ****
 
On Log Insight Server or any other server where you have openssl installed
- Edit the /etc/ssl/openssl.cng;
- Make sure the [req] section has the req_extensions parameter defined;
[req]
.
.
        req_extensions=v3_req #

obs: req_extensions specifies the section that defines extensions to add to a certificate request, where v3_req is the name of the section we want because it allow us to specify Subject Alternative Names (SAN).

- Add an appropriate Subject Alternative Name entry for the hostname or IP address of your server;
[v3_req]
.
.
        subjectAltName=DNS:server-01.loginsight.domain
        #subjectAltName=IP:10.27.74.215

- Save the file;
- Run the following command to generate your private key;
openssl genrsa -out server.key 2048

- Create a certificate signing request by running the following command;
openssl req -new -key server.key -out server.csr

**** Submit Certificate Request to a CA****

Now that you have your CSR it’s time to submit it to your CA and get your certificate back.

- In your Windows CA Server, run the following command to generate your certificate;
certreq -submit -attrib “CertificateTemplate:WebServer” server.csr server.pem

obs: “Certificate Template:WebServer” is the certificate template to be used, if you have another one you want to use just adjust the name accordingly.

**** Concatenate Certificate Files ****

Before you upload the certificate on Log Insight you need to concatenate them, so the root CA, intermediate CA (if any) an your certificate is all in on file.

- Create a new server-upload.pem file and open it in a text editor;
(it’s just an empty file)

- Copy the contents of your server.key file and paste it in server-upload.pem;
use the following format.
-----BEGIN RSA PRIVATE KEY----- 
(Your Private Key: server.key) 
-----END RSA PRIVATE KEY----- 

- Copy the contents of your server.pem file and paste it in server-upload.pem;
use the following format.
-----BEGIN CERTIFICATE----- 
  (Your Primary SSL certificate: server.pem)
-----END CERTIFICATE-----  

- If the Certificate Authorities provided you with an intermediate or chained certificate, append the intermediate or chained certificates along with the root certificate to the end of the server-upload.pem file;
use the following format.
-----BEGIN CERTIFICATE----- 
(Your Intermediate certificate: intermediateCA.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Root certificate: TrustedRoot.crt) 
-----END CERTIFICATE-----

- Save your server-upload.pem file;


**** Upload Certificate ****

Finally you have your certificate ready, it’s time to upload it.

- Log in on vRealize Log Insight Web Interface;
- In the configuration menu select Administration;
- Under configuration click SSL Certificate;
- Browse to your new certificate and click Open;
- Click Save;
- Restart vRealize Log Insight

If you are curious where all this information came from, please check:

 Let us know if it works for you !!!

Wednesday, June 10, 2015

vCloud Director Public Addresses


Most of vCloud Director implementations I’ve worked on where multi-cells implementations behind a load balancer to distribute the load and “hide” the cells from direct internet access.

In those scenarios you must configure the Public Address on vCloud configuration page, this way the cells will reply back to end users the public address instead of it’s internal address.
Starting with vCloud Director for Service Providers 5.6.3 there’s a few more flexible ways of configuring it.


Now we have options for:
- vCloud Director public URL
- vCloud Director secure public URL
- vCloud Director secure certificate chain
- vCloud Director public REST API base URL
- vCloud Director secure public REST API base URL
-vCloud Director public REST API certificate chain
 
As you could see we have a few new options, we could specify different address for HTTP and HTTPS access, but also when you specify the secure addresses you must include the certificate chain to be used, this means you wont use the internal cell’s certificate you specified during the cell’s installation.
This gives you the flexibility to have internal certificate provided by a internal CA and do real SSL OffLoad on your Load Balancer.




 Remember: Consoly proxy still no able to provide SSL Offload, so you still need that valid certificate internal to the cell.

 If you recall during cells implementation, there’s no API certificate bind to service during cell’s installation, so in the cases you want a different API URL than vCD URL having the option to specify it’s own certificate handy is awesome.



 The vCD's documentation was not update to reflect those new options yet, so I hope this posts helps to clarify a little bit about how to use them.

 

Tuesday, June 2, 2015

Demystifying vSphere Replication 6.0

As one of my blog's tradition here’s the updated information about vSphere Replication 6.0
Before we dive into the product’s operational limits, let’s see what new cool features have been introduced with VR 6.0

- Compression: now you can compress the data on the source site before send it over to the destination site. (must be on ESXi 6.0);



- Linux quiescing: used to quiesce your Windows boxes to prevent file-level crashing, now the feature is also available for the Linux ones;


- Full replication traffic isolation: with new vmkernel portgroups you can isolate replication traffic from end to end. (I’ll cover that in more details on a future post).


Besides the new features, we also had some enhancements on the scalability.

The maximum number of VRS still 10 (9 VRS + 1 VRMS, yes VRMS is also a replication server)
But the maximum VMs a single VRS can replicate has been increase from 100 to 200.
That means, using the solution at it’s maximum, you can reach a total of 2000 replicated VMs.

The old VR 5.1 and 5.5 Operational Limits KB has not bee updated to reflect the 6.0 enhancements, a new KB2102453 has been created instead.

If you are planning to replicate more than 500 VMs, here’s a few thing to be aware of:
- Adjust event maximum age at /opt/vmware/hms/conf/hms-configuration.xml
- On VRMS upgraded from previsous version the disk size cannot accommodate the internal database size so you need to increase the disk size too (assuming you are not using an external DB)

Check KB2102463 for the procedure.

 Good replication ; )

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions.

Most Viewed Posts

Blog Archive