Sunday, May 27, 2012

Add a Facebook Like button, twitter follow and tweet button with one code for Blogger

This post is valid and working as of may 2012.
* Please switch from new look of blogger to old classic style temporarily.
The following gives you 2 features of facebook(like+comment) and 2 features of twitter (tweet+follow)
1.Go to your blog and click on design on the right hand top corner on edit html and put a check mark on expand widget templates.
3. ctrl+f and search for <data:post.body/>
Right below that line paste the following and save template and you will see the facebook like button+tweet+follow on twitter button all together.
(replace @MrAmbiG with your twitter handle)

<b:if cond='data:blog.pageType != &quot;static_page&quot;'>
<div style='text-align:left;padding:5px 5px 5px 0;'>
<a class='twitter-share-button' data-count='horizontal' expr:data-text='data:post.title' expr:data-url='data:post.url' data-via='@MrAmbiG' data-related='' href=''>Tweet</a>
<script src='' type='text/javascript'></script>
<a class='twitter-follow-button' href=''>Follow @MrAmbiG</a>
<script src='' type='text/javascript'/>
<b:if cond='data:blog.pageType != &quot;static_page&quot;'>
    <iframe allowTransparency='true' expr:src='&quot;; + data:post.url + &quot;&amp;send=false&amp;layout=standard&amp;show_faces=false&amp;width=450&amp;action=like&amp;font=arial&amp;colorscheme=light&amp;height=35&quot;' frameborder='0' scrolling='no' style='border:none; overflow:hidden; width:450px; height:35px;'/>

for more refer my source :

Hot migration and cloning fails on vmfs 2 , 3 and on ESX(i) 4.x

Issue - unable to do hot sVMotion or hot cloning from one or two datastores.
“File is larger than the maximum size supported by datastore  VM/vm.vmdk”

Reason -
VM provisioned size: 259GB
used (thin) : 121GB
source datastore size : 1TB with 1mb block.
Destination datastore size: 2TB with 8mb block size.
The hot migration/cloning will not be successful since the bottleneck for any disk size which is being transferred during migration/cloning with any VM will be 1MB but the VM's provisioned size being more than 256GB it should be transferred with the block size of 2MB however it conflicts with the 1MB blocksize of the bottleneck of the datastore and thus it will be failed to migrte/clone while it is powered on.

Thursday, May 17, 2012

ESXi 5 Lun trespassing (lun thrashing) on EMC VNX

Problem description/symptoms/errors:
Issue with a new EMC VNX Lun.
The lun seems to be moving between service process A & B and EMC support claims that it is being initiated by the VMware.
10Gig storage back end network is configured but it fails from the host but when the MTU is changed it works fine. The default was MTU was 1500 and now it is 1344 on the host side on the vswitch and after doing this change, now the ping drop or the moving of the lun from the process A to B and vice versa is less but still occurring.

Action Taken:
changed the MTU back to 1500 and there was no ping drop or the movement of the lun between process A&B or vice versa.
Disabled the resignaturing esxcfg-advcfg -s 0 /LVM/EnableResignature  on all hosts and the trespassing stopped.

Friday, May 4, 2012

Updating or ugprading the VMware Hosts ?, Hold on not yet !!!

Issue : Updating/upgrading the VMware hosts from update 0 to update 1/2/3/4 or to a newer build number.
Concern: To avoid the management efficiency problems I have always insisted my customers to keep the first point of management/control center to be at a higher (or at-least equal) build number or upgrade level to that of the entities that it manages/controls.
vCenter Server is the primary point of management/login (vsphere client itself is just another tool to log into the vcenter server providing us a console to work on and to log into the host directly instead of the vcenter server) and it is best to maintain its build level at a higher (or equal) level compared to the hosts in it. The vcenter server is mainly designed to manage/control the hosts of the same or lesser build number and it does so by mainly through its vcenter agents which are installed in the host when you first add the host to the vcenter server. The vCenter mainly connects to the hosts and manages them using its vpxa agent in it and the ha with aam agents but they are designed for the hosts of the same or older build number. It is always safe to update/upgrade your vcenter first and then the hosts and then the VMs.

VMs Heartbeat, RVtools and ESX 4.1

Issue : Customer is using the RVTools an opensource tool to monitor the VMs.
the heartbeat of the VMs intermittently goes gray, green and red where as the VMs are running and working fine in the vcenter server.
Resolution :
It is a 3 node cluster with ESX 4.1 build 260247 and with vcenter 4.1 build 258902
Removed the nic for one of the VM and found that the VM did not restart automatically and the RVtools was still showing the heartbeat of the VM as green indicating that it does not use the network ping to check the heartbeat.
vmware-cmd -l listed all the running VMs including the one with the gray/red/green status of heartbeat in RVtools.
since the heartbeat of the VMs is conveyed to the vCenter through the vpxa agent by the hostd process of the host which is hosting the VMs, irrespective of its network status it can be safely assumed that now the heartbeat for the VMs are working fine. If the heartbeats are no longer received by the hostd, by default sent out every second, VM Monitoring will check if there is any Network or Storage I/O to avoid false positives. please make sure the VM monitoring under the Ha is turned on.
I or the customer did not know how the RVTools was calculating the heartbeat but the vcenter was receiving the heartbeats and the best way to check that is to reset a host with a non critical VM in it whose status is gray/red in the RVTools for the heartbeat column.

Thursday, May 3, 2012

ESXi 4.1 unable to change the ip in the DCUI

server : HP Blade
Issue: A new esxi 4.1 was added to the production cluster but it wont join the domain.
Management test in the DCUI fails.
Any attempt of changing the ip fails.
Solution: Install the HP version of ESXi 4.x
Cause: Drivers
What did not work :
tried updating the ip in the DCUI restarted the network services but no go.
Esxcfg-vmknic -i <ip address> -n <subnest mask> “Management Network”
but no go.
When we ping the host with the new ip address it is able to ping and when the host is shut down the ip starts pinging but in the DCUI it always shows the old ip.
Nslookup to the new ip shows up with the correct host but in the DCUI it still shows up the old ip which cant be changed.
Removed the host from the vCenter and connected to the vSphere client and the new ip is reflected in the management network portgroup.
Nslookup to the old (169.x.x.x) does not give any output.
Suggested reboot but no go.