Monday, April 3, 2017

vMotion of NSX EDGE gotcha

virtualpatel.blogspot.com: vMotion of NSX EDGE gotcha: Hi, Recently I was working on a brown field deployment of NSX and ran into an issue where we were not able to connect to the DHCP server ...

vMotion of NSX EDGE gotcha

Hi,

Recently I was working on a brown field deployment of NSX and ran into an issue where we were not able to connect to the DHCP server from a Logical Switch (which means the VMs are not getting IP addresses from DHCP server) which was a key.

If we put the VM on a regular VDS dvportgroup it gets the DHCP IP correctly.

So we started looking in to the issue further and engage VMware GSS to look in to the issue.

During the troubleshooting we had to decide the location of Edge and try moving it to a different host to verify if its not hitting any uplink issue.

As we were using vCenter Web Client and as soon as we tried migrating (vMotion) it to another host and we were prompted with the NIC mapping page. Where we need to map each interface exists on the NSX Edge to a corresponding portgroup or dvportgroup. Now we have only limited number of portgroups/dvportgroups existed on the Cluster and we could not map all the internal interfaces (which gets created by default on the Edge appliance).

The source were listed as "None" so not sure where to map them.

So we ended up using the vSphere client to migrate the Edge appliance, and boom....it got migrated with no notification about mapping all the interfaces. Just select the destination ESXi host and hit "Finish", and we are done.

We were then moved into the next phase of troubleshooting but the above just put me in a dilemma that the behaviour of Web Client is a bug or is it by design.

Interested in getting the answer from VMware so that I can clarify that with the existing and future customers on why to use vSphere client and what is the alternate methods to use when the Fat/Thick client will completely got removed by VMware??

Please leave the comment and share this.

Thanks for your time.




Tuesday, January 3, 2017

vRA and SCCM Timeout Issue

virtualpatel.blogspot.com: vRA and SCCM Timeout Issue: Hi, OK here I am again. Been away for few months working on various projects including vRA, vROPS, SRM, VIN, vRB etc.etc. And one of the...

vRA and SCCM Timeout Issue

Hi,

OK here I am again. Been away for few months working on various projects including vRA, vROPS, SRM, VIN, vRB etc.etc. And one of them is MSB. Yes its a new term I've learned and worked on with one of the Federal client along with VMware NSBU. 

But here today I'm going to discuss about the timeout issue with vRA and SCCM deployment.

Now before we begin let me give you the overview of what we are dealing with.

In my recent project Im working with VMware on a vRA Distributed architecture with a little bit of vRB and also integrating the SCCM on which the client is heaving depending on for VM/s deployment. 

Mainly these are windows 2008 R2 Std and Windows 2012 R2 Std VMs. They are leveraging SCCM to do all major tasks such as putting patches, updates, updating AV signatures, putting legacy apps, some monitoring apps such as WhatsupGold and Logrhythm etc. etc.



So once the VM is built in vRA its been handed over to SCCM for further provisioning and there is a default time out setting in vRA which is only 15 minutes.



So as you can see the default setting for SCCM machine registration timeout is 5 minutes. So now
lets assume you are doing few tasks using SCCM e.g. Installing OS, putting patches, doing AV updates, putting legacy or custom applications or softwares etc. etc. then you need time to finish all those tasks in the background on SCCM side. With having 5 minutes timeout vRA wont know what is the status of the SCCM VM as the whole process may not be finished and the gugent might not be updating vRA with any status at all so you may see the process/task in vRA as its still running and not completed and eventually the task will fail as no signal received by vRA in time (which is 5 minutes). So to avoid that you need to increase that time out setting by enough time that you can finish the required tasks on SCCM side before hitting the timeout window of vRA. We had to keep it at 45 minutes (screen shot below) on a safer side which accounts few reboots of the OS along with other tasks listed above.




After doing the above change we were started receiving finished tasks in vRA successfully which were handled by SCCM then gugent updates vRA server with appropriate status.

I will cover the SCCM and vRA in one of my upcoming blogs very soon.

Hope this will help integrating SCCM and vRA.

Please share and care.

Thanks for your time.


Friday, May 13, 2016

[Updated] Request to extend a chance for VCDX5

virtualpatel.blogspot.com: Request to extend a chance for VCDX5: Hi, I am taking the Liberty here to request VMware Education to extend the chance for Appearing a VCDX 5 Defense after the schedule of Oc...