DeepakNegi420's Posts

Having said that it would be pointless for VMware to do any developments on older version. It's vital to keep the technical currency up to date of underlying infrastructure.
Is it possible for you to provide vmkernel.log, hostd.log & VM's vmware.log file? 1- Are all virtual machines isolated from the network or just one? 2- When one virtual machine is isolated fr... See more...
Is it possible for you to provide vmkernel.log, hostd.log & VM's vmware.log file? 1- Are all virtual machines isolated from the network or just one? 2- When one virtual machine is isolated from network, can you ping it from a different VM from the same VLAN and see if it's reachable? 3- I noticed that you mentioned about replacement of VC module, did you try to roll back your change? 4- Are you running VM snapshot based backups?
You would want to restrict users from viewing the host and it's configuration. the best way to achieve this by creating a folder and a custom role in VMware roles and permissions and add the AD s... See more...
You would want to restrict users from viewing the host and it's configuration. the best way to achieve this by creating a folder and a custom role in VMware roles and permissions and add the AD security group or user to it.
VMware has also provided hotfix as a permanent fix, is it something which you can plan? Can you send the latest logs (Vmware.log & vmkernel) files.
This is strange behavior, Can you try resetting the ESXi from the DCUI mode and see if it comes back? Regards, Deepak Negi
My findings from the log files you provided- veem snapshot consolidation jobs is freezing the VM, refer to the following screenshot. You are running ESXi 5.0 version and there is a hotfix ava... See more...
My findings from the log files you provided- veem snapshot consolidation jobs is freezing the VM, refer to the following screenshot. You are running ESXi 5.0 version and there is a hotfix available to resolve this issue- Permanent fix- Install hotfix VMware ESXi 5.0, Patch Release ESXi500-201408001 (2080838) Description of the known issue- This issue occurs if the virtual machine generates data faster than the consolidate rate You can also workaround until you patch the VMhosts Shut down the virtual machine. Right-click the virtual machine and click Edit Settings. Click the Options tab. Under Advanced, click General. Click Configuration Parameters and add these parameters one at a time and check the result: Set snapshot.maxIterations to 20 (or higher). The default value is 10. If you cannot converge within default maxIteration (10), you just stun and perform synchronous consolidation, which may cause the virtual machine to be stunned for a long time. If you increase maxIterations to 20 or higher, then it is possible that the virtual machine will find a period within the maxIterations to perform synchronous consolidate. Change the snapshot.maxConsolidateTime to 60 seconds. The default value is 6 seconds. If you set the value to 60 seconds, the consolidate helper sees an opportunity to do the synchronous consolidate earlier (before the snapshot grows to a 30 minute issue after 10 iterations). Setting snapshot.maxConsolidateTime to 60 means that you can afford to have the virtual machine stunned for 60 seconds so the virtual machine can perform synchronous consolidate within the iterations. Note: There is a coefficient of 2 on maxConsolidateTime. A value of 60=120 seconds. The default is 6 but that stuns for 12 seconds. Set snapshot.maxIterations to 0. Setting snapshot.maxIterations to 0 causes the virtual machine to stun and perform synchronous consolidate in the first iteration only. This may reduce the stun time. Cheers, Deepak Negi Shut down the virtual machine. Right-click the virtual machine and click Edit Settings. Click the Options tab. Under Advanced, click General. Click Configuration Parameters and add these parameters one at a time and check the result: Set snapshot.maxIterations to 20 (or higher). The default value is 10. If you cannot converge within default maxIteration (10), you just stun and perform synchronous consolidation, which may cause the virtual machine to be stunned for a long time. If you increase maxIterations to 20 or higher, then it is possible that the virtual machine will find a period within the maxIterations to perform synchronous consolidate. Change the snapshot.maxConsolidateTime to 60 seconds. The default value is 6 seconds. If you set the value to 60 seconds, the consolidate helper sees an opportunity to do the synchronous consolidate earlier (before the snapshot grows to a 30 minute issue after 10 iterations). Setting snapshot.maxConsolidateTime to 60 means that you can afford to have the virtual machine stunned for 60 seconds so the virtual machine can perform synchronous consolidate within the iterations. Note: There is a coefficient of 2 on maxConsolidateTime. A value of 60=120 seconds.  The default is 6 but that stuns for 12 seconds. Set snapshot.maxIterations to 0. Setting snapshot.maxIterations to 0 causes the virtual machine to stun and perform synchronous consolidate in the first iteration only. This may reduce the stun time. Vmware KB VMware Knowledge Base
Great news, Cheers, DN
The best way is to revert patches - Follow the VMware KB VMware Knowledge Base Notes: Back up your configuration data before making any changes. For more information, see Backing up and r... See more...
The best way is to revert patches - Follow the VMware KB VMware Knowledge Base Notes: Back up your configuration data before making any changes. For more information, see Backing up and restoring ESXi configuration using the vSphere Command-Line Interface and vSphere PowerCLI (2042141). Reverting an ESXi host is only valid if the host was updated using these methods:  VIB installation or removal  Profile installation or removal  ESXi host update using VMware Update Manager  Updated from a ISO In the console screen of the ESXi host, press Ctrl+Alt+F2 to see the Direct Console User Interface (DCUI) screen.  Press F12 to view the shutdown options for the ESXi host.  Press F11 to reboot.  When the Hypervisor progress bar starts loading, press Shift+R. You will see the warning: Current hypervisor will permanently be replaced with build: X.X.X-XXXXXX. Are you sure? [y/n] Press Y to roll back the build.  Press Enter to boot.
Vous devez télécharger le client et l'installer. Il installera également des certificats lorsque vous le faites.
VMware published the advisory board with two of the three CV from two (CVE-2017-5715 & CVE-2017-5753 no information for CVE-2017-5754) refer to the VMware advisory link - VMSA-2018-0002 which ... See more...
VMware published the advisory board with two of the three CV from two (CVE-2017-5715 & CVE-2017-5753 no information for CVE-2017-5754) refer to the VMware advisory link - VMSA-2018-0002 which addresses CVE-2017-5715 - Addressed & CVE-2017-5753 - Not addressed An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. CVE-2017-5754 - No information published by VMware relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. Researchers have called this exploit "Meltdown".  Subsequent memory accesses may cause an allocation into the L1 data cache even when they reference otherwise inaccessible memory locations. As a result, an unprivileged local attacker could read privileged (kernel space) memory (including arbitrary physical memory locations on a host) by conducting targeted cache side-channel attacks. They have not provided any information on legacy VMware version prior to 5.1, pretty sure they are also affected. Let's wait for their next release. Best to follow this thread - Intel CPU bug - VMware fix on the way?
VMware published the advisory board with two of the three CV from two (CVE-2017-5715 & CVE-2017-5753 no information for CVE-2017-5754​) refer to the VMware advisory link - VMSA-2018-0002 whic... See more...
VMware published the advisory board with two of the three CV from two (CVE-2017-5715 & CVE-2017-5753 no information for CVE-2017-5754​) refer to the VMware advisory link - VMSA-2018-0002 which addresses CVE-2017-5715 - Addressed & CVE-2017-5753 - Not addressed Description of the vulnerability An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. CVE-2017-5754​ - No information published by VMware Description of the vulnerability relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. Researchers have called this exploit "Meltdown".  Subsequent memory accesses may cause an allocation into the L1 data cache even when they reference otherwise inaccessible memory locations. As a result, an unprivileged local attacker could read privileged (kernel space) memory (including arbitrary physical memory locations on a host) by conducting targeted cache side-channel attacks. They have not provided any information  on legacy VMware version prior to 5.1, pretty sure they are also affected. Let's stay tuned for their forthcoming release.
Yes, you will need to create a new VM and attach the old virtual machine VMDK to it. Just remember to use the -deletepermanenlty switch when you run it from powershell.
VMhost upgrade will not increase the storage array workload, I suggest check this- 1- Ask your storage team check for the response on these LUNs and also see if there is a rapid increase to work... See more...
VMhost upgrade will not increase the storage array workload, I suggest check this- 1- Ask your storage team check for the response on these LUNs and also see if there is a rapid increase to workload after upgrade? Storage administrator can check historical graphs. 2- Can you provide the logs in vmkernel.log file from your ESXi hosts ? You will see the errors related connections drops & established to storage array. 3- We faced similar issue few years ago and we had to reduce the I\O block size on ESXi to 32 KB, this was recommended by the storage vendor. You will need to do environmental research to reduce the block size. Datastore disconnection from storage This is the setting in advance page below- default is 32 MB. Provide historical graph of following, > Storage controller CPU usage - before and after upgrade > LUN I\O reads\Write stats  - before and after upgrade > Response time to LUNS > Review the performance and look at maximum I\Ops supported by storage controller if it's excessively unitized. Regards, Deepak Negi
It's the normal behavior of the virtual machine, if you run any task on the VM, virtual machines options are grayed out until the task is finished. ie -commit or delete Snapshots, storage vMotion... See more...
It's the normal behavior of the virtual machine, if you run any task on the VM, virtual machines options are grayed out until the task is finished. ie -commit or delete Snapshots, storage vMotion. You will notice power setting and edit setting of the virtual machine is grayed out. In this case, the new virtual machine did not finish the cloning task. Regards, DN
VMware has not released any fix at this point. Whilst we wait for VMware to release a patch,  few consideration in planning even patching the linux and windows servers. Obviously, Analyzing the c... See more...
VMware has not released any fix at this point. Whilst we wait for VMware to release a patch,  few consideration in planning even patching the linux and windows servers. Obviously, Analyzing the current cluster utilization would be the key to ensure that adequate capacity is available to meet the new demand of 8% to 29% overhead. Also there is a possibility of increased overhead of memory in VMhost if Inter-Virtual Machine Transparent Page Sharing is enabled in VMhosts. It's disabled by default after 5.5 update 2 but check with VMware if you have this enabled. Regards, Deepak Negi
Yes, The virtual machine will need to be registered in the ESXi inventory in order to use powershell. It sounds like VMDK file is locked by a process, follow the below VMware article to find out ... See more...
Yes, The virtual machine will need to be registered in the ESXi inventory in order to use powershell. It sounds like VMDK file is locked by a process, follow the below VMware article to find out more. VMware Knowledge Base Do you also have VM snapshot based backup solution integrated with the VMhost? Regards, Deepak Negi
Is this host running in a cluster or standalone? Check memory Swap in and Swap out graph on the host. You will notice the swap going up frequently if there is a memory contention on the host. ... See more...
Is this host running in a cluster or standalone? Check memory Swap in and Swap out graph on the host. You will notice the swap going up frequently if there is a memory contention on the host. Ensure that you have VMware tools installed on the host, it will allow the host to reclaim the unused memory. Regards, DN
Are you experiencing this error on multiple hosts? Look at the disk performance stats for the virtual machines running on the volume. What's the model of the blade & storage array?
My response in green- Since you have mentioned HA so I'm assuming you have adequate memory to perform this activity without downtime. Do you have HA errors to satisfy HA (As it calculates the ... See more...
My response in green- Since you have mentioned HA so I'm assuming you have adequate memory to perform this activity without downtime. Do you have HA errors to satisfy HA (As it calculates the slots) in your cluster? I'd suggest you to keep DRS fully automated and put one of the hosts into maintenance mode and it will automatically migrate the VMs off and also you need to monitor the utilization of your hosts, ideally DRS should be able to take care of it and ESXi will not move to maintenance mode until all Vms are off from it. Hello, I need some feedback here.  We have 5 hosts (each has about 128 GB memory) with a total of 96 VMs.  We need to bring each host down to add memory (can be done different days).  I generated a report from Veeam that tells me which host is the ideal candidate to bring down plus other factor such as the VMs could be shutdown during the process. Host 1 has 19 VMs and is a candidate to take down first.  9 VMs can be shutdown during the whole process. Here is my thought process: 1) Shutdown the 9 VMs on host 1 You may not require to do this. 1A) Set HA to not shuffle the machines around since I am doing this manually. HA has nothing to do with the vMotion. 2) VMotion 10 VMs to other hosts      -  take down other VMs on other hosts to lessen resources (on other hosts, I also have the ability to take down a few VMs) DRS should be able to manage the workload across all ESXi hosts.  QUESTION: As the VMs are shutdown, the "Memory Usage" will reduce correct for each host?  But I still have to make sure the VMs total memory allocation is lower than the limit of 128 GB event hough some machines are powered down? Memory usage will reduce when the VMs are off the host in form of migration or shutdown state. Use DRS and following approach is good then, 3) Put in maintenance mode and shutdown host 4) Add memory 5) Start host and turn on any down machines, VMotion, etc I can have one host with the new added memory run (greater than other hosts) for days correct?  The hosts don't need to have equal memory? You can have one hosts with more memory in a cluster however it's recommended to keep the same amount of memory in all of the hosts. For a limited time it should not really matter if one hosts has more memory.
Hi, I'd suggest to keep this option turned off. Domain controller should always sync the time to associated windows client. The best practices is to uncheck the VM Tools set to "Synchroniz... See more...
Hi, I'd suggest to keep this option turned off. Domain controller should always sync the time to associated windows client. The best practices is to uncheck the VM Tools set to "Synchronize guess time with host" and domain controllers will take care of the time sync to your exchange servers. Imagine a situation if you have a faulty cache battery in your ESXi and a restart of the host will reset time to when the firmware was upgraded and this may cause the VMs to use to ESX time during startup and on top of it VM tools will restric the VM to use the ESX time, this means application outage so having VM Tools set to "Synchronize guess time with host" unchecked you mitigate this risk and even if they restart using a wrong time. Secondly esnure that you have domain controller to provide NTP services to your ESXi environment. Check if you have any time sync error in system event. Cheers, Deepak Negi