PhillyDubs's Accepted Solutions

http://www.yellow-bricks.com/2015/02/17/vsphere-60-breaking-large-pages/http:// http://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/ From my experience, most ... See more...
http://www.yellow-bricks.com/2015/02/17/vsphere-60-breaking-large-pages/http:// http://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/ From my experience, most of the "issue" is because of large pages. When I trick vSphere in to using small pages everything works wonderfully and I can cram many times the amount of virtual machines on the server.
This is a known bug - http://kb.vmware.com/kb/2052917
I'm not sure their reasoning for that, but it seems like a pain in the butt. Why don't you just export the logs with the vSphere Client? File -> Export -> Export System Logs Or Use the vSph... See more...
I'm not sure their reasoning for that, but it seems like a pain in the butt. Why don't you just export the logs with the vSphere Client? File -> Export -> Export System Logs Or Use the vSphere Support Assistant that will allow you to collect and automatically upload logs? http://www.vmware.com/products/datacenter-virtualization/vcenter-support-assistant/overview.html
There's no way to have a magic calculation to determine how many VM's fit on a host as workloads are rarely ever perfectly consistant nor is hardware all the same across every environment. Wit... See more...
There's no way to have a magic calculation to determine how many VM's fit on a host as workloads are rarely ever perfectly consistant nor is hardware all the same across every environment. With that said, you  have found your bottleneck, CPU. It is typically seen as best practice to start with 1vCPU for your virtual machines and scale up if more vCPU is needed. Start by reducing the number of vCPU on virtual machines, especially ones that don't even peak above 60% total usage. Also, to find which VM is consuming your CPU, just observe which virtual machines are consistently using the most CPU and the highest amount of vCPU. Those virtual machines will typically be the ones that have high CPU Ready % and will cause an impact to other virtual machines that want CPU resources. Someone in this thread has already explain what CPU Ready time is, I'm not sure what else you want to know about it. It is typically the counter I use to see if my vCPU is overprovisioned though.
"If I put one of the Nehalem hosts into maintenance mode, remove it from the current cluster and place it in a new cluster with EVC turned on with the EVC mode set to "Nehalem", will I then be ab... See more...
"If I put one of the Nehalem hosts into maintenance mode, remove it from the current cluster and place it in a new cluster with EVC turned on with the EVC mode set to "Nehalem", will I then be able to vMotion VMs from the other two Nehalem hosts in the current cluster to the new EVC enabled cluster?" Yes. You are going from Nehalem to Nehalem, no issues. "I understand that the VMs on the Westmere hosts will need to be powered down before migrating them to the new Nehalem EVC cluster but will I be able to VM motion the VMs from the Penryn hosts to the new Nehalem cluster?" Yes. As long as the current instruction set is lesser than or equal to Nehalem, you can do this. "Also the Nehalem hosts contain two processor types: X5550 and X5560. Would this have any impact on vMotioning VMs from a non-EVC cluster to a new Nehalem EVC cluster?" As long as the non-evc cluster is Nehalem(or lesser), it should not be an issue. All you are doing with EVC is masking which instruction sets can be offered to the virtual machines.
Bay 6 or 5? Your Word document earlier said that the volume labeled "VMstorage" is mapped to "Blade_Bay_5". If you are confident that you have properly mapped the disk and do not see it at all... See more...
Bay 6 or 5? Your Word document earlier said that the volume labeled "VMstorage" is mapped to "Blade_Bay_5". If you are confident that you have properly mapped the disk and do not see it at all when viewing your storage controllers in VMware, it's probably best to call VMware and see if their storage support can help you figure out why you can't even see the storage when viewing your controller.
Observer the worker logs for any "could not find" errors. I looked through yours and found this: 2012-12-21T13:33:17.620+01:00 [02980 error 'task-5'] Could not find symmpi.sys in \\.\vstor2-mn... See more...
Observer the worker logs for any "could not find" errors. I looked through yours and found this: 2012-12-21T13:33:17.620+01:00 [02980 error 'task-5'] Could not find symmpi.sys in \\.\vstor2-mntapi10-shared-EC48ED48000010000000000016000000\WINDOWS\Driver Cache\i386\driver.cab 2012-12-21T13:33:17.635+01:00 [02980 error 'task-5'] Unable to find symmpi.sys in the specified CAB files 2012-12-21T13:33:17.635+01:00 [02980 error 'task-5'] Reconfiguration failed with: converter.fault.FileNotFound 2012-12-21T13:33:17.635+01:00 [02980 info 'task-5'] Rolling back the reconfiguration transaction... Go to System32\Drivers on the source server and determine if symmpi.sys is in that folder. If not, copy it from another known working 2003 VM and also copy it to drivers.cab in Windows\Driver Cache\i386\driver.cab Run the conversion again and opt to not power on the new VM and to not power off the source, this way you can verify if the process works. If it does, great! If not, observe the worker logs again, searching for "could not find" or "reconfiguration failed with" to determine the failure reason. I have much experience with this exact issue and it is almost always something to do with symmpi.sys
Hi Kahonu, Since the KB(1029513) you're referencing applies to earlier versions of ESX/ESXi than just 5, you also see the blurb that cold migration may rename the files. Here is the full text:... See more...
Hi Kahonu, Since the KB(1029513) you're referencing applies to earlier versions of ESX/ESXi than just 5, you also see the blurb that cold migration may rename the files. Here is the full text: KB 1029513 Note: Storage/Cold Storage vMotion or using the console renames only the folder names and not the files in ESXi 5.0. This behavior was changed to support Storage DRS on ESXi 5.0. For more information, see vSphere 5 Storage vMotion does not rename virtual machine files on completing migration (2008877). A virtual machine's files may be renamed during a disk migration operation, such as Cold Storage Migration, or by manually renaming them in-place from the ESXi/ESX console. Select your preferred method. Alternatively, a virtual machine could be cloned to a new virtual machine using the Clone method in vCenter Server or using vCenter Converter, and deleting the old virtual machine. The text starts off by making sure you understand that in ESXi 5.0, the file names are not changed. I agree, the information is a bit ambiguous below and something VMware should clarify by perhaps saying "For previous versions of ESX/ESXi, a virtual machines...".