Zsoldier's Tech Blog

If there is an easier or non-root required method to what I’ve outlined here, please I’m ALL EARS. Summary: I pretty much hate Samsung or Android, not sure where to direct my h8, but whatever.  I wasn’t going to let it beat me.  Essentially I needed to connect to an AP that uses 802.1x WEP, PEAP, and MSCHAPv2 radius authentication to get access.  Not that difficult on my iPhone w/ the use of profiles, but Android/Samsung wasn’t as easy.  Here it is in a nutshell: Root your Vibrant (SDK method preferred) Use the SDK to pull your current wireless config Modify the wireless config entry you have for the AP that you are trying to connect to. VOILA! successful connection. Nitty Gritty: Follow the instructions on how to root your Vibrant. Once your vibrant has been rooted, you need to download and install the SDK . Turn off your phone’s Wifi, and turn USB debugging on (Settings –> Applications –> Development). This is where it gets interesting (Windows method): Open a c

Summary: One VM out of several thousands became inaccessible via network and vCenter console access (sample pictured below).  Other symptoms included: Slow vMotion to vMotion just not occurring within the cluster that had that one VM failing. VMWare vMotion failure @ 10% ScsiCore: 1181: Sync CR (opcode ##) at ### (wid #) <—Error in vmkernel log Cannot browse datastore w/ questionable VM from vCenter VM Console shows below error when trying to access problem VM. Resolution: “Trespass” or “Failover” the LUN w/ the questionable VM to another storage processor (SP).  This immediately stopped all errors and all unaffected VM’s on that LUN continued to run while releasing whatever lock was placed on the LUN causing these ‘wonky’ issues. Other related reading from VMWare: http://kb.vmware.com/kb/1018675 http://kb.vmware.com/kb/1003734

Summary: Essentially the title sums it up.  A user tries to connect to a pool, but they get an error stating that no desktop resources are available to them.  A look @ the admin console shows either the VM is in “Ready” or “Disconnected” status. Possible Resolutions: Reset the “VMWare View Agent” service on all or a specific VM in a pool. Reset the VM from the vCenter management console. Check your DHCP pools, make sure all addresses are not reserved already. I believe the View admin console lacks the code to display something like ‘offline’ when it loses communication w/ a VM’s View Agent.  It’s interesting because the View broker is aware that a VM’s View Agent is offline based on it’s debug logs (Usually found under C:\Documents and Settings\All Users\Application Data\VMWare\VDM\logs), but you would never be the wiser because the admin console shows everything to be fine.  It seems that status is only updated when it ‘expects’ something back from the Agent like after initial