A client of mine has been suffering from really poor performance on some of their wireless devices. Namely some WinCe 4.1 based hand held scanners. Thier WAP is a Sonic Wall TZ-190 with firmware 4.2.1. Pinging the handheld, would have about 4 out 20 packets dropped, another 5 in the 400~500ms, and another 5 greater than 500ms range. Here are the ping times from my notebook (I am sitting about 6 feet away from it):
Reply from 172.16.35.1: bytes=32 time=55ms TTL=64
Reply from 172.16.35.1: bytes=32 time=811ms TTL=64
Reply from 172.16.35.1: bytes=32 time=2ms TTL=64
Reply from 172.16.35.1: bytes=32 time=4ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=4ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=1576ms TTL=64
Reply from 172.16.35.1: bytes=32 time=6ms TTL=64
Reply from 172.16.35.1: bytes=32 time=5ms TTL=64
Reply from 172.16.35.1: bytes=32 time=4ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=52ms TTL=64
Reply from 172.16.35.1: bytes=32 time=56ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=2ms TTL=64
Reply from 172.16.35.1: bytes=32 time=5ms TTL=64
Reply from 172.16.35.1: bytes=32 time=308ms TTL=64
Just on a whim, i changed the access point to brodcast only 802.11b instead both 802.11b & 802.11g, now take a look at the ping times:
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=4ms TTL=64
Reply from 172.16.35.1: bytes=32 time=4ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=2ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=611ms TTL=64
Reply from 172.16.35.1: bytes=32 time=364ms TTL=64
Reply from 172.16.35.1: bytes=32 time=457ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=4ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=2ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=2ms TTL=64
Reply from 172.16.35.1: bytes=32 time=2ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Reply from 172.16.35.1: bytes=32 time=3ms TTL=64
Ramblings of an IT Professional (Aaron's Computer Services) Aaron Jongbloedt
Upgrading to Vsphere 5 & demo period
When installing a new Vsphere environment one gets a 60 trial license, that includes all the bells & whistles of the full VMware suite. Including one of my personal favorites SVmotion. This feature allows one to move a running VM between datastores, very cool. Often during hardware & software refreshes we use this tool, for instance getting a new SAN; VMware even suggests utilizing the trail period to complete these tasks!
Unfortunately, if one upgrades their Virtual Center, IE one already has a 64bit Windows OS running Virtual Center 4.X and one does an upgrade to Virtual Center v5.0 over the top; there is NO trial period! The licenses are required immediately! Bummer! Also if one has only purchased a package, say VMware Essentials, there is no SVmotion capabilities.
Unfortunately, if one upgrades their Virtual Center, IE one already has a 64bit Windows OS running Virtual Center 4.X and one does an upgrade to Virtual Center v5.0 over the top; there is NO trial period! The licenses are required immediately! Bummer! Also if one has only purchased a package, say VMware Essentials, there is no SVmotion capabilities.
VMware: Moving a Virtual, Virtual Center from one datastore to another.
During a SAN migration we moved all the VM's from a datastore on the older SAN to a datastore on the newer SAN. Not a big deal, except when it came to moving Virtual Center which is also VM.
My first attempt was to use VMware Converter and do a P2V. Simply launch VM Converter, point it at the ESXi host that is currently housing the VM, and choose another host as the destination. Unfortunately, one cannot do that. Turns out that one cannot use an ESXi host as a destination if that host belongs to a VMware cluster, aka if Virtual Center manages it. DOH! See VMware KB article.
What I ended up doing, was shutting down the VC VM. Connecting directly to the ESXi host, browsing to the old data store, right clicked the folder that contains the VM, select "Move", chose the destination datastore, click next, wait. Once done, remove the old VM from inventory, go back to the datastore, and the folder where that VM lives, find the XXXX.vmx file, right click, "add to inventory" start the VM up. Vmware will complain, choose "I moved it", and life is good!
Another option: I haven't tried this yet, but supposidly one can do an SVmotion using the CLI.
Storage vMotion Command-Line Syntax
My first attempt was to use VMware Converter and do a P2V. Simply launch VM Converter, point it at the ESXi host that is currently housing the VM, and choose another host as the destination. Unfortunately, one cannot do that. Turns out that one cannot use an ESXi host as a destination if that host belongs to a VMware cluster, aka if Virtual Center manages it. DOH! See VMware KB article.
What I ended up doing, was shutting down the VC VM. Connecting directly to the ESXi host, browsing to the old data store, right clicked the folder that contains the VM, select "Move", chose the destination datastore, click next, wait. Once done, remove the old VM from inventory, go back to the datastore, and the folder where that VM lives, find the XXXX.vmx file, right click, "add to inventory" start the VM up. Vmware will complain, choose "I moved it", and life is good!
Another option: I haven't tried this yet, but supposidly one can do an SVmotion using the CLI.
Storage vMotion Command-Line Syntax
VMware migration from 3.5 to 5: Snapshots & CID mismatch
During a migration from an ESX v3.5 to ESXi v5.0, we ran across a stumbling block. Since the new SAN was implemented using VMFS v5, and ESX v3.5 cannot see that, a new volume was created in the VMFS 3 format, and both hosts were attached to this LUN. We used sVmotion to move the VM from the local storage of the ESX 3.5 box to the SAN for the v5 enviroment.
What I didn't know, is that despite snapshot manager reporting that there weren't any snapshots present; there was! Turns out that a flawed backup software had created four uncommited snapshots. The VM would no longer boot!
During the sVmotion, the ESXi 5 snapshot manager did pick this up and report them; okay so let's use Snapshot Manager to commit the snapshots. After some time, Snapshot manager reports that all snapshots have been taken care of; however the VM still would not boot, and browsing the data store yielded that the snapshot files where still there.
At this point, VMware has a nice feature called "Consolidate Snapshots". After some time all of the snapshot files were now gone, however the VM still would not boot! An error message of a "CID mismatch" showed up. Following this KB article from VMware we were able to fix the issue.
In a nut shell, the vmdk descriptor file has a pointer linking it to it's parent drive, and one had to go in and edit this line.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007969
What I didn't know, is that despite snapshot manager reporting that there weren't any snapshots present; there was! Turns out that a flawed backup software had created four uncommited snapshots. The VM would no longer boot!
During the sVmotion, the ESXi 5 snapshot manager did pick this up and report them; okay so let's use Snapshot Manager to commit the snapshots. After some time, Snapshot manager reports that all snapshots have been taken care of; however the VM still would not boot, and browsing the data store yielded that the snapshot files where still there.
At this point, VMware has a nice feature called "Consolidate Snapshots". After some time all of the snapshot files were now gone, however the VM still would not boot! An error message of a "CID mismatch" showed up. Following this KB article from VMware we were able to fix the issue.
In a nut shell, the vmdk descriptor file has a pointer linking it to it's parent drive, and one had to go in and edit this line.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007969
VMware Partner EXchange 2012
Feb. 2012 over 4300 people gathered in Las Vegas a week of all things Vmware. This picture is of the temporary lab set up for the event.
Android phones & Exchange 2010
During an Exchange 2010 upgrade, I ran across some phones that would not work. After much gnashing of teeth & pulling of hair it turns out that certain accounts (usually those w/ Domain Admin. privileges) located in the default Users OU had this check box pertaining to inheritable permissions unchecked, and one could not check that box while they existed in that OU. The solution was to move those users to a different OU, and tick this check box.
Barracuda Backup 390 Appliance
A pretty slick 1U appliance. Barracuda does good job of simplifying backing up an enterprise. Unfortuantly when making things simple, it often times becomes hard to get certain jobs done. One of the issues we had was deselecting certain files/folders from being backed up, AND having a filter also excluding some of those same files creates really long error logs. Another thing that I find annoying, is that when one is manipulating a job, such as excluding a folder it takes a long time for the UI to bring up the folder/file list, because the information is being read from the client, up to Barracuda's main servers, then back down to your webpage; even if you are in the same room!
It has a pair of SATA drives in it; it does dedupe & compression. There is an option to replicate jobs to "the cloud", which is really just Barracuda's main site. In this case the client has 400gb max. cloud storage; so only their crucial stuff gets replicated.
Another Day at the Office
Memory speed makes a difference
During a PC upgrade; in this case an E-Machine T5234, I pulled out 3gb of pc-5300 ram and replaced it w/ 4gb of pc-6400 ram. Doing so the Windows System Expirence for the "Memory Operations Per Second" went from 4.8 to 5.7.
Subscribe to:
Posts (Atom)






