Unallocate IP from IP Range in vRA 6.2.x

This came as a requirement from one of the clients. They are using vRA 6.2.2 where they have migrated few Deployments (vSphere VMs) from one Reservation to Other and ended up in a situation that old Reservation based Network profile which was having IP Range configured from where these set of VMs were holding IPs allocation remained as it was and at the same time same set of VMs which are now moved to new reservation from where they picked up new IPs from the local IP range of that reservation.

Simple ask from customer was to make sure that old IP Range based IPs which were allocated in the name of moved VMs should be released so those can be used by new deployments

Little research on IaaS sql DB and found a way to resolve this.

Used following select statement to see if particular VM Name is having multiple network IP allocated againsts it.

select * from staticipv4address where virtualmachineid in (select virtualmachineid from virtualmachine where virtualmachinename in (”));

if above statement returns 2 or more entries for one VM, execute following update statement to set IP address to be unallocated which is not being used.

update staticipv4address set virtualmachineid = NULL, StaticIPv4AddressState = 1 where virtualmachineid in (select virtualmachineid from virtualmachine where virtualmachinename in (”)) and IPv4Address=”;

I did make sure to keep Backup of IaaS DB in case if that’s needed.
There will not be a need of vRA service outage.


VMware vForum Online 2016

Attend vForum Online 19th April, 2016 where featured speakers are VMware CEO Pat Gelsinger and VMware CTO Chris Wolf, talking SDDC, End User Computing and the Hybrid cloud.

There will be 8 Hands-On-Labs to test-drive a variety of VMware Solutions. Certain unique product demos by VMware system engineers and unlimited access to eBooks, tech-tips and other product related resources.

For more information and registration, Click Here


Simplified exam booking process

on 05/03/2016, PeasonVue and VMware announced a new process of Booking or Managing your VMware Certification exams.

As part of this, now you don’t have to request Authorization for Exam and then separately launch PearsonVue portal to book the exam. There’s no need to even maintain two accounts across these two websites.

All you got to do is, GO in your http://mylearn.vmware.com account. And then simply click on ‘Getting Started’ Tab. That’s where under Exam Authorization section, you will find a link to launch ‘Pearson Vue: Manage Exam’, which is single sign-on with your current mylearn portal account. See following screenshot

Screen Shot 2016-03-06 at 4.25.58 PM.png

Ref: http://www.pearsonvue.com/vmware/


Delete Firewall rules in VCSA 6.0

Let’s say we have vCSA 6.0 appliance in place, where some firewall rules are created.

Managing this is easy using vSphere Web Client -> Administration -> System Configuration -> Nodes -> <your vCSA node> -> Manage -> Settings -> Firewall
(List of rules would appear like following screenshot)

Screen Shot 2016-02-10 at 10.51.08 PM
Click on ‘Edit’ button
Screen Shot 2016-02-10 at 11.10.59 PM
here there are buttons to Add new rule, Edit an existing rule, Re-order rules using up/down arrow, and the last button is to Delete.

Now if you want to see list of firewall rules using vCSA console, command is

api.com.vmware.appliance.version1.networking.firwall.addr.inbound.list (Following output)

Screen Shot 2016-02-10 at 10.56.32 PM

and from this list if you want to delete one of the rule, remember rules are being displayed in the order they are there in GUI output, where very first rule record is index number 0, second record is index number 1 and so on

And to delete one of the record from the list, use following command.
api com.vmware.appliance.version1.networking.firewall.addr.inbound.delete –position 0
This will delete very first record from the list. and the second record which is there in the above screenshot will become the index position 0. see following screenshot

Screen Shot 2016-02-10 at 11.19.40 PM

Now, if you want to delete All the rules in firewall in just one go.

api com.vmware.appliance.version1.networking.firewall.addr.inbound.delete –all true
this will make sure that all the rules in vCSA 6.0 firewall gets deleted.

(Note: in my commands, I have actually used double dash without any space in between which is visible in screenshots but the Text I have typed in blogpost is not making it very clear)


vSphere 5.5 or higher and Reliable Memory Technology

like we know ECC (Error-Correcting Code) is a great feature we have to tackle soft errors happening in RAM, without causing OS to fail, but ECC protects us from single soft error in a memory block at a time, so if there are multiple soft errors in a single memory block or hard errors on one or multiple cells in main memory, this will surely cause OS Kernel to panic. This will then result into longer downtime in terms of going through variety of steps to identify faulty module to replace it. Or resetting OS (in case of multiple soft errors) with all it’s application services. If this was a virtualised environment with VMware ESXi  or any such other hypervisors then we know there will be multiple VMs running and the all go down along with the hypervisor.

This is where Reliable Memory Technology (RMT) comes into picture which is basically a hardware feature which works along with supported OS (like ESXi 5.5 or higher). This will make sure that if during ongoing operations, any multi-bit soft error in a DIMM or hard error occurs, it will be detected by RMT and will take corrective actions in such a way so it won’t trigger OS Kernel to panic.

For Example, let’s say there was a hard error in one of the DIMM, system will detect it and mark faulty cell and some cells around it as non-usable. so that current OS operations will continue but after next reboot, OS will not see those faulty cells because hardware is not even presenting those anymore.

RMT proves to be really great when it comes to minimise downtimes due to Memory Fault related kernel panics, and also avoiding to replace whole memory module due to hard errors in DIMM.

if you have vSphere 5.5 or higher with Enterprise or Enterprise plus edition license, and if you hardware has it, then in your ESXi host you will be able to see Reliable memory using following command.


List of References:
Tech. White Paper from Dell about RMT
Third-party blog post1
Third-party blog post2


Long Distance vMotion in vSphere 6

With the help of dynamically resized network socket buffer, vSphere 6 is capable to support vMotion of a VM across vCenter servers located far apart. Network round trip latency >100 ms (upto 150 ms) is tolerated/supported.

basic requirements to achieve long distance vMotion are as bellow

1) L2 Streched VM Network
2) Multi-site gateway support
3) Secure vMotion network between both the sites

Use cases of Long Distance vMotion

1) Multisite Load balancing
2) Permanent migration
3) Follow-the-sun-scenario support
4) Disaster Avoidance

VMware pushes the envelope with vSphere 6.0 vMotion


vSphere 6, Clear state

Memory management in vSphere 5 happens with following 4 states.

High State: 100% of minFree available (<100% and >=64%, TPS is in action)
Soft State: 64% of minFree is available (<64% and >=32%, Ballooning is in action)
Hard State: 32% of minFree is available (<32% and >= 16%, Compression, Page Swapping)
Low State: 16% of minFree is available (<16%, Page Swapping)

ESXi 5.x Memory state chart

while in vSphere 6, this has changed, a new memory management state has been introduced called Clear state which is equivalent to previous High state. So now in ESXi 6 following are memory management states available.

High State: 300% of minFree available (<300% and >=64%, TPS is in action)
Clear State: 100% of minFree available (TPS is in action, this is previous version High State)
Soft State: 64% of minFree is available (<64% and >=32%, Ballooning is in action)
Hard State: 32% of minFree is available (<32% and >= 16%, Compression, Page Swapping)
Low State: 16% of minFree is available (<16%, Page Swapping)

ESXi 6 Memory states chart

In Short, an additional state which has been introduced called Clear state, and High State is tripled with compare to last version, now it’s 300% of minFree value of an esxi host, this is purely so TPS gets a chance to be triggered long before it hits Clear state and carry on acting on memory accordingly.

Reference: Duncan Epping’s blog about vSphere 6, Memory states & vSphere 6 Resource Management Guide


ESXi 6 – minFree value

minFree is associated with High Memory state of ESXi 6 or prior to it.

If you are wondering how ESXi is calculating minFree value, here is the math behind it.
Value of minFree is 899 MB for the ESXi host with upto 28 GB RAM.
host with more than 28 GB RAM, minFree is calculated as bellow
minFree = 899 MB (upto 28 GB RAM) + 1% of remaining capacity of RAM in that host.

Like an ESXi host with 100 GB RAM has minFree = 1619 MB
899 MB + 720 MB (1% of 72 GB)