vNEX's Posts

Hi John, 2. I also noticed that the VM's are running at the normal speed when viewed/operated from within the VSphere Web Client console. (how would you interpret this?) When you connect via RD... See more...
Hi John, 2. I also noticed that the VM's are running at the normal speed when viewed/operated from within the VSphere Web Client console. (how would you interpret this?) When you connect via RDP client you go directly to VM through network configured exclusively for VMs and their traffic. On ESXi side is involved vSwitch/vDS/ portgroups configured for VMs... When you connect to VM via vSphere Web/Client Console all interaction activities (MKS) goes directly to ESXi host on ports 902/903 to VMware Authorization Daemon (vmware-authd). On ESXi side is involved vSwitch/vDS/portgroup (+vmkernel port) configured for management network. As you know management should be separated so it has to be on different subnet which means that  maybe different physical switcehs/modules/ports are involved in communication. But when we stay at ESXi hardware equipment you have mentioned that your host has just one quad port card integrated on motherboard which is used by all vSwitches. Don't know your exact design so I just guess ... So from my point of view it could be a faulty port used for virtual machines network ... but it's just a shot in the dark. You will certainly prove this with a brand new NIC you've ordered. But despite all of this look at the adapter/s dedicated for VMs traffic and double-check Speed/Duplex configuration. It should be the same as on physical switch port. See: VMware KB: Configuring the speed and duplex of an ESXi or ESX host network adapter What status shows VMTools and what virtual network adapters are you using in all the VMs...? What shows network metrics DRPTx, DRPRx  in ESXTOP? Finally check and try to disable all NIC Offload features in Guest OS: • TSO (TCP Segmentation Offload) • Offload IP Security • Offload TCP/IP Checksum and Receive Side Scaling (RSS) feature I look forward to hearing from you, Good Luck! P.
Answer for LAST EDIT ... of your original question:) ***EDIT*** I guess another way to state this is that I need to know what the collection interval is for Alarms.  Are we talking about the 20... See more...
Answer for LAST EDIT ... of your original question:) ***EDIT*** I guess another way to state this is that I need to know what the collection interval is for Alarms.  Are we talking about the 20 sec "Real-Time" interval for collection... For me its logical that vCenter Alarms using 20 sec "Real-Time" interval for "CPU Ready Time" and other perf statistics otherwise they would be useless ... Unfortunately I didn't find any official reference also.
Hi Matt, In my opinion Condition Length has nothing to do with Ready Time calculation it's just the custom value which you personally prefer for Alarm to be  triggered. For monitoring Ready T... See more...
Hi Matt, In my opinion Condition Length has nothing to do with Ready Time calculation it's just the custom value which you personally prefer for Alarm to be  triggered. For monitoring Ready Time higher than 3% set Condition Warning or Alert to 600ms for VM with 1 vCPU or 1200ms  for 2 vCPU ...etc. When Condition Length is set to 5 minutes you will compare data for ReadyTime from 15 samples .... Condition Length set to 30 seconds is in this scenario useless use 20s or 40s or 1 minute ....etc. Regards, P.
Hi, All hardware appears to be in good shape. Please check Hardware status tab on the host and status of all sensors... On unmanaged host -> Configuration tab - > Hardware - > Health Status ... See more...
Hi, All hardware appears to be in good shape. Please check Hardware status tab on the host and status of all sensors... On unmanaged host -> Configuration tab - > Hardware - > Health Status Then you can take a look at log files and search for: error, warning, fault, panic, backtrace ... "events" For ESXi host: /var/log/vmkernel.log /var/log/vobd.log VM log file: vmware.log - in same directory as the virtual machine's files If it's possible upload them... If you are unable to find nothing suspicious in the logs use ESXTOP tool as next level ... For troubleshooting with ESXTOP check out these excellent sources: http://www.yellow-bricks.com/esxtop/ Interpreting esxtop Statistics http://www.vmworld.net/wp-content/uploads/2012/05/Esxtop_Troubleshooting_eng.pdf See also: VMware KB: Troubleshooting ESX/ESXi virtual machine performance issues VMware KB: Troubleshooting network performance issues in a vSphere environment VMware KB: Determining if virtual machine and ESX host unresponsiveness is caused by hardware issues VMware KB: Poor network performance or high network latency on Windows virtual machines VMware KB: Troubleshooting poor local storage controller performance for VMware ESXi/ESX VMware KB: Using esxtop to identify storage performance issues for ESX / ESXi (multiple versions) Performance Links - Master List Regards, P.
Hi, the resources limits in 5.5 config maximus applies also for free ESXi 5.5 hypervisor with only one exception: The vSphere 5.5 Hypervisor retains the 8 vCPU/virtual machine limit Se... See more...
Hi, the resources limits in 5.5 config maximus applies also for free ESXi 5.5 hypervisor with only one exception: The vSphere 5.5 Hypervisor retains the 8 vCPU/virtual machine limit See: VMware KB: Licensing for vSphere 5.5 For features comparison between paid versions and free hypervisor look at: VMware KB: Product offerings for vSphere 5.x Another restriction in FREE edition is remote management via (PowerCLI, vCLI, SDK ...) where you are allowed only to read-only operations. Regards, P.
Hello, here is the explanation: VMware KB: vCenter Server Alarm on an ESXi host reports the message: Error (1) saving state to /bootbank Regards, P.
For better understanding there should be some patching Flowchart in KB 2076665, because maybe is little bit tricky and confusing but I can see it quite clearly: 1. If you are on a previous (n... See more...
For better understanding there should be some patching Flowchart in KB 2076665, because maybe is little bit tricky and confusing but I can see it quite clearly: 1. If you are on a previous (non-U1) build, you have to patch your host with both patches in this order (If you want to go for fixed Complete Update 1 release FIRST - VMware KB: VMware ESXi 5.5, Patch Release ESXi550-201404020 SECOND - VMware KB: VMware ESXi 5.5, Patch Release ESXi550-201404001 If you want just address and resolve OpenSSL Heartbleed issue without step to U1 install only "ESXi550-201404020" KB2076665 Notes: Note: After you have patched your ESXi hosts with VMware ESXi 5.5, Patch Release ESXi550-201404020, you should not upgrade your hosts to ESXi 5.5 Update 1 as the hosts will again we vulnerable to the OpenSSL Heartbleed issue.After applying VMware ESXi 5.5, Patch Release ESXi550-201404020 on ESXi 5.5 hosts, you should only patch your systems with VMware ESXi 5.5, Patch Release ESXi550-201404001 to update your hosts with all bug fixes that were provided with ESXi 5.5 Update 1. And for me the main reason/recommendation not to patch a current non-Update 1 hosts to Update 1 applies only for those who already  installed "ESXi550-201404020" because  installing U1 release on them makes again those host be vulnerable to OpenSSL Heartbleed issue. As I understand the only right way to go for ESXi 5.5 Update 1 is path I mentioned above = bypass VMware KB: VMware ESXi 5.5, Patch ESXi550-Update01: ESXi 5.5 Complete Update 1 and install "ESXi550-201404020" first and then "ESXi550-201404001 (which contains fixed U1 image)". P.
Hi Stan, I understand it like this (regarding to VMware KB: Resolving OpenSSL Heartbleed for ESXi 5.5 - CVE-2014-0160 A) Everyone with ESXi 5.5 GA build: 1331820 and others with images l... See more...
Hi Stan, I understand it like this (regarding to VMware KB: Resolving OpenSSL Heartbleed for ESXi 5.5 - CVE-2014-0160 A) Everyone with ESXi 5.5 GA build: 1331820 and others with images listed below (ie. all non-Update 1 Hosts: All hosts under Build Number: 1623387) should apply this patch:      VMware KB: VMware ESXi 5.5, Patch Release ESXi550-201404020 ESXi 5.5.0 hosts ESXi 5.5.0 hosts patched with ESXi550-201312101-SG bulletin that contains VMware_bootbank_esx-base_5.5.0-0.7.1474526.vib . ESXi 5.5.0 hosts patched with ESXi550-201312401-BG bulletin that contains VMware_bootbank_esx-base_5.5.0-0.7.1474528.vib . ESXi 5.5.0 hosts patched with ESXi550-201403101-SG bulletin that contains VMware_bootbank_esx-base_5.5.0-0.14.1598313.vib . ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-standard image profile that contains VMware_bootbank_esx-base_5.5.0-0.7.1474526.vib . ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-no-tools image profile that contains VMware_bootbank_esx-base_5.5.0-0.7.1474526.vib . ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-standard image profile that contains VMware_bootbank_esx-base_5.5.0-0.7.1474526.vib . ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-no-tools image profile that contains VMware_bootbank_esx-base_5.5.0-0.7.1474526.vib . ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-standard image profile that contains VMware_bootbank_esx-base_5.5.0-0.14.1598313.vib . ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-no-tools image profile that contains VMware_bootbank_esx-base_5.5.0-0.14.1598313.vib . Next you should do this: After applying VMware ESXi 5.5, Patch Release ESXi550-201404020 on ESXi 5.5 hosts, you should only patch your systems with VMware ESXi 5.5, Patch Release ESXi550-201404001 to update your hosts with all bug fixes that were provided with ESXi 5.5 Update 1. B) Everyone with ESXi 5.5 Update 1 already installed (all host with Build Number: 1623387 and above) should apply only this patch:      VMware KB: VMware ESXi 5.5, Patch Release ESXi550-201404001 And dont forget to follow this instructions: Post installation instructions: After installing the above-mentioned patches accordingly,  you need to perform certificate revocation/replacement and change the passwords. Regards, Petr
Hi, please follow KB below ... to completely eliminate existing risks you have to change your host's passwords after patching and certs replacement. VMware KB: Resolving OpenSSL Heartbleed fo... See more...
Hi, please follow KB below ... to completely eliminate existing risks you have to change your host's passwords after patching and certs replacement. VMware KB: Resolving OpenSSL Heartbleed for ESXi 5.5 - CVE-2014-0160 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Post installation instructions: After installing the above-mentioned patches accordingly,  you need to perform certificate revocation/replacement and change the passwords. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hello John, to get .pem file working with SSL Tool you have to include complete certificate chain in this container... - Certificates in PEM container must be in x509 (BASE64) ... NOT in DE... See more...
Hello John, to get .pem file working with SSL Tool you have to include complete certificate chain in this container... - Certificates in PEM container must be in x509 (BASE64) ... NOT in DER - when you open it in text editor they must start with:  -----BEGIN CERTIFICATE----- ends with: -----END CERTIFICATE----- - If you are using subordinate CA for issuing certificates in your domain you must include its certificate in PEM file! - All certificates in .PEM file must be in reverse order so when you open the file first must be vCenter server certificate, second Sub CA and last Root CA You can create PEM container with copy command and keep exact order: copy /B <path>rui.crt + <path>SubCA64.cer + <path\>RootCA.cer chain.pem After you will have PEM file created open it and check certificates order, vCenter first, Sub second and Root at the bottom. Avoid putting some extra blank lines between certificates, there should be no space before and after any certificate. Once you have chain.pem and private key from vCenter (rui.crt) certificate you can start with SSL Tool. P.
Hi John, replacing vCenter certificates after 5.1 release has come was always little bit tricky because lots of new components are there (SSO etc.) Whole process has many manual steps so that... See more...
Hi John, replacing vCenter certificates after 5.1 release has come was always little bit tricky because lots of new components are there (SSO etc.) Whole process has many manual steps so that's why there is plenty of space to make a mistake. So that's why VMware come with SSL Automation Tool which simplifies the process in many ways. Once you have all certificates, private keys and .pem files prepared it's really quick and straightforward to apply them. No manual steps is needed to refresh trusts between vCenter components everything is done by SSL Automation Tool. Check it here: VMware KB: Deploying and using the SSL Certificate Automation Tool 5.5 Only one think is missing in that KB the way how to create .PEM files, although it is simple ... If you need help with this just ask... Regards, Petr
Hi, André is right, I can see from picture enclosed that you running ESXi on laptop, or it's just monitor from Lenovo on the picture... ?! Ca you provide more details about your HW, please?... See more...
Hi, André is right, I can see from picture enclosed that you running ESXi on laptop, or it's just monitor from Lenovo on the picture... ?! Ca you provide more details about your HW, please? If you have ESXi installed directly on non-server (laptop) HW is always hit or miss ... because some components are usually unsupported (ie. disk controllers, NICs ...) I found very simmilar PSOD for ESXi which was caused by missing C-State information to be exposed by the BIOS...see: VMware KB: Fujitsu RX300 S5 fails with a purple diagnostic screen with &quot;no symbols&quot; on VMware ESX/ESXi 4.1… PSOD type is Exception 14: Page Fault A page fault (Exception 14) occurs when the page being requested has not been successfully loaded into memory. For detailed info see: VMware KB: Understanding Exception 13 and Exception 14 purple diagnostic screen events in ESX 3.x/4.x and ESXi 3.x/4… So it is definitely worth to check your HW components support on VMware HCL and update your HW firmware like BIOS etc. to latest revisions. If you found your CPU supported but other components not, think about nested virtualization using VMware Workstation. More on this you can find here: VMware KB: Support for running ESXi/ESX as a nested virtualization solution VMware KB: Installing ESXi 5.x in VMware Workstation Regards, Petr PS: Because you have 5.5 U1 build: 1623387 I would recommend update your image to latest build which address and resolves Heartbleed vulnerability issue, see: VMware KB: VMware ESXi 5.5, Patch ESXi-5.5.0-20140404001-no-tools
Here is the patch: VMware KB: VMware ESXi 5.5, Patch ESXi-5.5.0-20140404001-no-tools Summaries and Symptoms This patch resolves the following issues: PR1227131: The OpenSSL version is updat... See more...
Here is the patch: VMware KB: VMware ESXi 5.5, Patch ESXi-5.5.0-20140404001-no-tools Summaries and Symptoms This patch resolves the following issues: PR1227131: The OpenSSL version is updated to 1.0.1g to address the Heartbleed vulnerability. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-0160 to this issue. For further details on remediation steps for ESXi 5.5, see KB 2076665. Note: To completely  resolve this issue, you also need to replace certificates and change passwords. For more information, seeResolving OpenSSL Heartbleed for ESXi 5.5 - CVE-2014-0160 (2076665).
Hi Kweli, there is nothing special in proxy configuration at VUM we using it and everything works fine....which version of VUM are you using? Sometimes the GUI does not tell the truth, ... See more...
Hi Kweli, there is nothing special in proxy configuration at VUM we using it and everything works fine....which version of VUM are you using? Sometimes the GUI does not tell the truth, can you check proxy setting in VUM config file here: C:\Program Files (x86)\Vmware\Infrastructure\Update Manager\vci-integrity.xml Look for: <proxySettings>    <useProxyServer>true</useProxyServer>    <proxyServer>name or IP address of the proxy server</proxyServer>    <proxyPort>port number of the proxy server</proxyPort> </proxySettings> There shouldn't be any http/https:// prefixes in <proxyServer> field .... Also check proxy settings in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Update Manager\Proxy If all the settings are correct look at the VUM log here: C:\ProgramData\VMware\VMware Update Manager\Logs\ You can also try for troubleshooting purposes enable trivia logging for VUM see: VMware KB: Enabling trivia logging in VMware Update Manager Regards, Petr
Hello Rohail, just for clear picture, you have three independent environment’s one with 5.5 vCenter and hosts and other 5.0 based and 5.1 based? What is the combination of vCenter/hosts ver... See more...
Hello Rohail, just for clear picture, you have three independent environment’s one with 5.5 vCenter and hosts and other 5.0 based and 5.1 based? What is the combination of vCenter/hosts versions/build you using together for testing this, you can't manage 5.5 host's with 5/5.1 vCenter that's clear ... It is clone on the same Host ore between two hosts? Resides cloned VM on shared storage accessible to both sides source/destination? is used same physical storage for source/destination? In some circumstances cloning using management network so it depends of it's speed.... (if it's true check speed and duplex settings on network adapters) Verify if your storage support the hardware acceleration functionality (VAAI) with vSphere 5.5 and check state of VAAI on hosts... Have you check your HW compliance with vSphere 5.5 on VMware HCL...? and check if your firmware is up to date ... Regards, Petr
Hi Mauro, it's a fresh install or agent upgrade? Did you check installation path if it's correct/exist "C:\Windows\CMAgent\Installer\Packages\EcmInstallSimpleInstaller6_0.exe"  ? - any fol... See more...
Hi Mauro, it's a fresh install or agent upgrade? Did you check installation path if it's correct/exist "C:\Windows\CMAgent\Installer\Packages\EcmInstallSimpleInstaller6_0.exe"  ? - any folder redirection policy on the server? - verify if system variables are correct You can also try manual installation of agent via .msi package. Try install agent via msiexec with verbose logging  "msiexec /i CMAgent[version].msi /L*v install.log", from this log we can get more detailed info... Log can be analyzed with  Windows Installer Log Analyzer: Wilogutl.exe (Windows) Or enable MSI verbose logging on the system: (DONT forget to turn it off after troubleshooting:) [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer] Reg_SZ: Logging Value: voicewarmupx and check Msi*.log in %temp% folder ... Regards, Petr
Hi Tom, just a little note, using 8GB/USB stick have some limitations...please, check this KB: Installing ESXi 5.x on a supported USB flash drive or SD flash card (2004784) VMware KB: Inst... See more...
Hi Tom, just a little note, using 8GB/USB stick have some limitations...please, check this KB: Installing ESXi 5.x on a supported USB flash drive or SD flash card (2004784) VMware KB: Installing ESXi 5.x on a supported USB flash drive or SD flash card "Limitation when installing on USB flash drive or SD flash card: When installing ESXi onto a USB flash drive or SD flash card, if the drive is less that 8GB is space, this prevents the allocation of a scratch partition onto the flash device. VMware recommends using a retail purchased USB flash drive of 16GB or larger so that the "extra" flash cells can prolong the life of the boot media but high quality parts of 4GB or larger are sufficient to hold the extended coredump partition." Because of this also check your scratch partition location in your case it will probably be located in ramdisk instead on USB stick. It's always better to have persistent location for scratch partition. Check your host Advanced settings, "ScratchConfig" ( /tmp/scratch/ = RAMDISK)if scratch is redirected to RAM you can change it to some persistent location by following above or this KB: Creating a persistent scratch location for ESXi 4.x and 5.x (1033696) VMware KB: Creating a persistent scratch location for ESXi 4.x and 5.x When this happen to your VM's can you check if you are able to browse host datastore and find VM's folders? If you can see VM folder try to open folder and right-click on .vmx file, then select "Add to Inventory" then you will have your VM back... What you see when you edit (healthy and registered) VM under options tab - > General options. What is in VM config file and working directory path? Just for Info: Changing VM working directory (location of .vmx, vswap, delta.vmdk files) is possible when you add a line to the .vmx configuration file for the virtual machine, specifying a full path to the directory on a datastore for the workingDir option: workingDir = "new_path_location see: VMware KB: Creating snapshots in a different location than default virtual machine directory In the meantime can you check your hardware compatibility with ESXi 5.5 here: VMware Compatibility Guide: System Search Regards, P.
Because no reference like "unsupported" can be found in whole vCenter 5.0 documentation  we can assume that YES. I never had any problems with special characters in vCenter 4.x and 5.0 ... Is... See more...
Because no reference like "unsupported" can be found in whole vCenter 5.0 documentation  we can assume that YES. I never had any problems with special characters in vCenter 4.x and 5.0 ... Issues with special characters in passwords comes with arrival of vCenter 5.1 and SSO service, same for 5.5 Also beware of using special characters in VMs and datastore names in vCenter 5.x Troubleshooting issues with virtual machines or datastore names containing special characters (2046088) http://kb.vmware.com/kb/2046088 For vCenter 5.0 and ESXi See: Prerequisites for the vCenter Server 5.0 Upgrade http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc_50%2FGUID-093777CF-BB5A-4D23-A41D-5B791789E33C.html Upgrading to vCenter Server 5.0 best practices http://kb.vmware.com/kb/2003866 Other sources: ESX and ESXi 4.x and 5.x password requirements and restrictions http://kb.vmware.com/kb/1012033 Host Password Strength and Complexity http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc_50%2FGUID-942E8E23-D2CE-49B0-8B39-F31EF6D0519B.html Password Requirements http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc_50%2FGUID-DC96FFDB-F5F2-43EC-8C73-05ACDAE6BE43.html&resultof=%22special%22%20%22characters%22%20%22charact%22 If you want a bulletproof answer you can contact VMware support for acknowledgement... Regards, P.
Hi Bhwong, these errors are always quite complex, can you gather more detailed information, take a look at these log files on both (source/destination) hosts: /var/log/hostd.log; /var/log/v... See more...
Hi Bhwong, these errors are always quite complex, can you gather more detailed information, take a look at these log files on both (source/destination) hosts: /var/log/hostd.log; /var/log/vmkwarning.log and vmware.log of failed VM Q:What is the possible cause for the vMotion to fail when all the previous VMs have migrated successfully? A: What is in general the difference between successfully migrated VMs and failed VM? Check VM HW configuration: - HW version, CPUID masks, Under VM options tab, are you using some of the specific  Advanced settings? Is there any difference in datastore/disks types (RDM?) which is used by failed and success VM ? Have you tried Storage vMotion VM to another datastore and then vMotion to different host? It is the VM with existing snapshots? What OS is installed inside VM? Is there any difference in source and destination hosts/builds compared to successfully migrated VMs? Q:Why does vCenter attempt to take a snapshot and restart this VM for? Is the system account named user? A: vSphere HA reset was triggered because you have enabled VM Monitoring feature/service. When VM stops sending its heartbeats via VMwareTools and there is no I/O activity (Disk/Network) for the VM on the host vSphere HA will try to reset VM i defined intervals...(this symptoms is typical for frozen VM "An error occurred while restarting virtual machine after taking a snapshot. The virtual machine will be powered off." - this sentence could be misleading, better info will be in logs I mentioned above. Q: Why can't vMotion just abort the migration and continue to run on the existing ESXi 4.1u2 when it encounter problem, instead of just freeze there infinity A: My guess is that something goes wrong on source host side which cause VM to freeze, if VM is frozen/non-responsive there is no recovery that can be taken by vMotion. If something wrong happen on the destination host vMotion usually successfully reverts back whole operation and VM continue running on source host. Q:Is there a better way to recover the VM without killing it's process and power up? I don’t think so... Regards, Petr