Forcefully terminate running vms что это
How to Stop/Kill a Stuck Virtual Machine on Hyper-V?
If your virtual machine running on Hyper-V is stuck for some reason, stopped to respond and doesn’t start/stop/reset after clicking the corresponding buttons in the Hyper-V console, the only way out to fix this is to forcibly kill the process responsible for this VM on the host OS. We’ll show you how to force restart stuck Hyper-V VMs running on Windows Server 2016/2019 without rebooting the entire host and all running VMs (if you do not have a Hyper-V HA cluster and Live-Migration).
Hyper-V VM Stuck in the “Stopping/Starting” State
Suppose, that one of your Hyper-V VMs is stuck in the Stopping (Stopping-Critical) or Starting (Starting x%) state.
The guest OS doesn’t respond and “Turn Off”, “Shut Down” and “Reset” buttons in the Hyper-V Manager either are unavailable, or return the following error when pressed:
Hyper-V Manager Stuck on “Connecting to Virtual Machine Management Service”
If your Hyper-V does not show virtual machines in the Hyper-V Manager console, and returns the “Connecting to Virtual Machine Management service” error, you need to restart the vmms.exe (Hyper-V Virtual Machine Management service) process. This is a safe operation and will not interrupt the running VMs. The easiest way to restart the vmms.exe process is through the vmms service using the services.msc console or with the PowerShell service management cmdlets:
Get-Service vmms | Restart-Service
How to Kill a Hung VM Process in Task Manager?
The only way to force shutdown restart such a stuck VM without rebooting the whole Hyper-V host is to end its running workflow in the guest OS. All VMs on the Hyper-V host are started using the vmwp.exe process (Virtual Machine Worker Process). To search for a process, you need to find out the GUID of the virtual machine.
You can get the VM GUID through the Hyper-V Manager console. Open the Hyper-V server settings. In the Server section, the location of the VM configuration files is shown (in our case it is D:\VMStore).
Open this directory in File Explorer and find the folder with the same name as your virtual machine has. Copy the GUID that is specified in the name of the VM configuration file with the *.vmcx extension.
Run the Task Manager and go to the Details tab. All virtual machines are running in their own instance of vmwp.exe. To determine which process is responsible for your VM, you need the GUID of the hung-up VM you obtained earlier. Locate the process vmwp.exe that has the GUID of your VM in the User name column. Kill this process (End Task).
The virtual machine will be forced to stop. Now you can do anything with it.
Killing a Frozen Hyper-VM using PowerShell
It is much easier to find and kill the process of the hung-up virtual machine using the PowerShell CLI. Run the PowerShell console with the administrator privileges (your account must be added to the local “Hyper-V administrators” group).
You also need to kill the VM process by its GUID. You can get the VM GUID by its name. For example, to get the GUID of the VM with the name SVM-GUARDEDHOST1, run the command:
$VMGUID = (Get-VM «SVM-GUARDEDHOST1»).ID
If you don’t want to type the full name of the VM, you can list all the VMs registered on this Hyper-V host:
Get-VM | Select Name, Id
Copy your VM GUID from the resulting list.
Find the vmwp.exe process identifier (PID) for this VMGUID:
Then, using the Stop-Process command, you must force-terminate this process:
Stop-Process ($VMWMProc.ProcessId) –Force 
This is the easy way to forcefully terminate the working process of a hung-up Hyper-V virtual machine.
Hyper-V: Failed to Change VM State
Sometimes it happens that even after killing a hung-up VM process, you cannot turn on the VM. Moreover, it freezes in the Starting state with an error:
In this case, check the following options:
VMware Front Experience
How to use the ESXi Patch Tracker to update ESXi
About a year ago I started my VMware ESXi Patch Tracker service. This is a set of automatically generated web pages that show informations about all available ESXi patches. Its primary purpose is to give you an easy way to track the patch history and get alerted about new patches once they are released. You can subscribe to it by RSS feed, E-mail and Twitter.
Recently I have added new functionality to the Patch Tracker that enables you to update your ESXi hosts in a very convenient way. Here is how:
The first thing that you need to do is enabling remote Tech Support Mode (better known as ssh shell access) for your ESXi host. KB1017910 explains various ways to do this. Beginners will likely just use the vSphere Client GUI. There is also a video on the VMwareKB Youtube channel available that explains it: In the Host Configuration tab click on the Security Profile link under Software on the left, then click on the Services / Properties link in the upper right corner. This will open a dialog where you can start and stop ESXi services. In the list find the service labeled SSH and click on the Options button. In the Options dialog press the Start button o start the service and close the dialog with OK.
Then close the Service Properties dialog by clicking on OK again. Now you are able to connect to your ESXi host with an ssh client, e.g. the Windows program putty.
Use it to log in to your host as the root user.
Next open the VMware ESXi Patch Tracker in a web browser. Navigate to the ESXi version that you want to upgrade to, e.g. 6.0. The page is sorted chronologically, and you will always find the latest patch at the top. At the time of this writing that is Update 1b. When you now click on the Imageprofile name (ESXi-6.0.0-20160104001-standard in this case) a window will pop up that includes some esxcli commands:
Now just do what’s written there. Select all the displayed text (in Windows you can use the Ctrl-A keyboard shortcut for that) and copy it to the clipboard (Ctrl-C in Windows), Now select the putty window with your ESXi shell session and click on it with the right mouse button to paste and execute the commands:
The first command will open the ESXi firewall for outgoing http/https requests, the second command will pull the Imageprofile information and associated software packages (VIB files) from the VMware Online Depot and update your system with them. The third command will undo the first command (just to revert to the system defaults.
All you need to do now is to reboot your host by manually entering the reboot command. Before that make sure that there are no running VMs on the host, or they will be forcefully powered off.
Please note that this method will only work when your ESXi host has a direct outbound Internet connection to download packages from the VMware Online Depot. Otherwise you need to download the Offline bundle patch from MyVMware and use that to update your host. The ESXi Patch Tracker Help page has more information about that.
vSphere 6.0 GA Installation Tips & Findings
Posted By Jon on Mar 14, 2015 | 0 comments
I have been waiting for the vSphere 6.0 GA release for a while and when it finally came I logged into my VMware portal and grabbed the ISO for ESXi and vCenter. I deployed it to a spare Dell 2950 III (2x Quad Core Xeon 5410 and 32GB of RAM, PERC6/i, etc.) just to test out since my “production” Lenovo TS140 runs my Plex server, file server, this site and many others. I will eventually upgrade to vSphere 6.0 on the Lenovo TS140 but for now I need to figure it out and find out what might and might not work. So, until then, this Dell 2950 III will serve as a test environment. VMware blacklisted a whole bunch of network and storage drivers for this release, though most of the blacklisting was aimed toward consumer hardware.
As usual, the actual ESXi installation is extremely straightforward. It is the typical yellow screen installation that you’ve come to love from previous versions:
I didn’t experience anything super special during installation. You still need hardware RAID controllers if you are going to use multiple disks for the ESXi installation. Nothing of interest really stood out during the ESXi ISO installation (I use Dell’s iDRAC to deploy the ISO remotely). The only thing of interest from the actual console is when shutting down a host using the F12 option you now have the option to “Forcefully terminate running VMs” which is kind of handy in panic situations:
Once you’ve got ESXi 6.0 installed on your host you’re set to start deploying vCenter (or managing the host with the standard client… more on that…). For my test installation I’ve decided to create my vCenter Server 6.0 in Windows 2012 R2 Datacenter on the ESXi 6.0 host itself. I thought about putting the vCenter Server 6.0 on my ESXi 5.5 setup but I decided against it. When you mount the vCenter 6.0 ISO and do the autorun you get a nice looking installation prompt:
One thing you’ll notice that’s different from, say, a vCenter Server 5.5 installation is that there’s no option for “Simple Install” (or Single Sign-On, Web Client, etc.) – you can only just install the vCenter Server or not. I find that extremely nice! And, the actual installation does not take EONS. It does take time, but with “Simple Install” you would install each module and sometimes you’d get a prompt that the process has stopped responding while the installation loads the next module. The only real option you have is whether you’re going to separate your Platform Services Controller from your vCenter Server:
The only time you’d want to do that is in larger installations with multiple vCenter Servers. So, for our purposes we’d choose the “embedded deployment” (which I think is a bit of misnomer as it’s not really embedded, it’s just that the services are combined…). So, the reason I decided to not deploy my vCenter 6.0 Server on my ESXi 5.5 U2 setup is because of this next window:
Great 🙁 Mind you, I captured that screenshot from my Terminal Server simulating the vCenter Server installation, I have 3GB on this VM but do have 4GB on my vCenter Server 5.5 allocated, but now it requires 8GB. You can get around that requirement by running the installation with “SKIP_HARDWARE_CHECKS=1” but obviously performance may be compromised. Since I can only put 32GB of RAM in my Lenovo TS140, I can’t afford having two vCenter servers each with 4GB of RAM allocated. Once you’ve got yourself past this screen the only remaining option is whether you want to install the Postres database (new to vSphere 6.0) or use a external MSSQL instance. I chose Postgres for ease.
You’re done! Once installed you can access your vCenter Server through the web client. Thing to note, though, is that if you decide not to install vCenter for licensing reasons or what have you, then you can only manage a single host through the new vSphere client. By that, I mean you can manage any single host but not a vCenter Server with the vSphere client. That is different to vSphere 6.0 – formerly you could manage the vCenter Server from the vSphere client so if you didn’t prefer the web client it wasn’t the end of the world. Now, however, you don’t really have a choice if you want to use the advanced features of HA Clustering or Snapshots, etc.
If you’re experienced in setting of former versions of vCenter Server you might have noticed that we never touched on SSO and domain information. This threw me for a loop. When I tested the vSphere 6 Beta I didn’t bother enabling Microsoft AD-based SSO authority and left the default administrator@vsphere.local account in place as my primary access. So, when I went into the new web client I created the Datacenter, cluster, added the host, etc. I went to set top-level permissions on the vCenter Server using an AD group I created called “VMware Admins” but I could only select from “vSphere.local” and “ConwayVC6.conway.local” – neither of which are my domain:
I knew I had to get into the settings that setup authority for login, but had a hard time finding it. Eventually, I found a menu I hadn’t yet tried:
Thanks VMware! “Administration” was on the left-hand column of the “Home” screen of the web client in 5.5 – right out there in the open! They made shortcuts through the “Getting Started” pages for each module for creating the vCenter, the Datacenter, the Cluster, attaching the Host… but not doing anything about SSO regarding domains. If they did, then I apologize, as I missed it – but yeah, took me about 20 minutes to find this! I guess I should RTFM, right?
Once in administration you have the options for setting up SSO authority sources:
Once you’ve added users or groups from your domain to various roles you can login with “Use Windows session authentication”… well, with one caveat! Maybe you’re like me and you have a homelab on ESXi 5.5 U2, a test ESXi 6.0 GA, and then use everything from ESXi 4.0 – 5.5 U2 at your work. Well, I’ve noticed some questionable results so far having both 5.5 U2 and 6.0 GA web client plugins installed in Firefox 36. If I install the VMware Web Client Plug-in for 6.0 I can “Use Windows session Authentication” but if I then go to my ESXi 5.5 U2 web client to log in the option is not available… sometimes. Maybe it just needed to kind of reinstall everything one after the next, but I thought it was worth mentioning. Sometimes it seems to work, sometimes it doesn’t and the annoyance was that I have to close Firefox to install either plugin, so that’s something to note.
One last thing I am excited about is that VMware has included Guest OS selection which includes RHEL 7 and CentOS 7 which I know vSphere 5.5 U2 had in the web client, but the standalone client seemed to have issues applying a customization file to a RHEL7/CentOS7 box. A colleague and I were looking for this as recently as last week for a project. If the version of Linux isn’t predefined here in the Guest OS list then it can become difficult to apply guest customization files to a template/VM. There are some hacks that can let you apply a customization to a RHEL 7 box by making vSphere 5.5 U2 think it’s RHEL 6, but we were not able to get that to work. Additionally, I noticed that the vSphere 6.0 GA web client also has a Guest OS selection for CoreOS which will be interesting to play with, also.
And finally… the new web client. I could be mistaken but I thought I heard that the goal was to make the new web client HTML5 without Flash. I don’t know if that was a to-do or a dream or what, but I have a fresh installation of Windows 2012 R2 w/o Flash and when I visited the web client URL I was prompted to install Flash – bummer. I am sure this is documented somewhere, but I thought the goal was to break the reliance of Flash… didn’t happen, at least not in GA. This is not a big deal to me overall unless I want to manage the vCenter Server from a server w/o Flash installed – a lot of times we need client approval to install any software so that could become annoying. The whole point of a web client is to remove the burden of having to have the vSphere client installed from a management point. But, if I need Flash installed, that’s no better – I have to go through the same process in order to install the vSphere client on a server as I do to install Flash and in fact, I bet some clients would be more willing to have the client installed than Flash which is notorious for security issues.
However…
The web client speed is much better. MUCH, much better. It’s totally tolerable at least in all of the menus needed for everyday ESXi administration. In the vSphere 5.5 U2 web client you will right-click a VM, the menu will pop up with all the options available, and then a bit later, the options will go gray and unavailable. It sometimes takes a few seconds to get to a point where you can actually click an option from the right-click menu. However, in the vSphere 6.0 GA web client the options are already either gray or available when you right-click. Navigating from a top level to a sub-level of the menu is crisp and snappy and doesn’t have the same chunky feeling that 5.5 U2 had. So, much improved! Though, I guess that’s a requisite considering the web client is now the only real way of administering a vCenter environment.
Anyway these are my initial findings and tips up front – it’s long, it’s wordy, and it’s not much more than skin deep, but I thought I’d share my initial impression. I hope to build a larger vSphere 6.0 GA environment shortly and will make a post soon with new findings, tips, issues, etc. I am going to be looking to migrate my ESXi 5.5 U2 Lenovo TS140 host over to ESXi 6.6 GA soon. It might involve clustering some stuff to minimize downtime… we’ll see!
SYANG.IO
Shujian Yang’s personal website
Sharing ideas about cybersecurity, digital forensics and programming.
VMware VMs Not Running Problem
06/03/2017
Problem
Today something weird happened on my VMware Workstation 12 Player. I was unable to run any of my virtual machines(VMs) stored on my computer. When I tried to run a VM, an error message pop up, saying:
VMware Player cannot connect to the virtual machine. Make sure you have rights to run the program, access all directories the program uses, and access all directories for temporary files.
Failed to connect pipe to virtual machine. The system cannot find the path specified.
If start VMware Workstation Player in administrator mode, the second part of the error message became:
The vmx process exited prematurely.
Cause
Lots of attempts were performed based on the solutions found on Internet, including disabling anti-virus software, re-installing VMware Workstation. But none of the methods worked.
Combined with the previous error message displayed by VMware Workstation, I was able to determine that the vmware-vmx.exe encountered some errors brought by gameudp.dll while starting and was terminated.
Solution
Further research about this gameudp.dll indicates that it is not a part of the original Windows system file and is safe to be removed. So I backed up this file, then deleted it from C:\Windows\System32. After that, I restarted VMware Workstation. This time, the VM successfully started and the problem was solved.
Interestingly, later I restore the gameudp.dll back to its original location. The VMware Workstation still functioned normally. The actual cause of the problem is yet to be found and the role of gameudp.dll is still not clear.
Hope this article may help someone who has the same problem as I did!
VMware vSphere 7.0 update 3 — что сломали на этот раз
Статья прислана читателем бложика.
Перед началом дальнейшего прочтения надо вспомнить, что VMware vSphere состоит из двух мегаменов — ESXi на хостах и правящий всеми vCenter. Мне лично больше нравится таблица тут, но ее не так быстро обновляют.
Читаем «что там нового»
Как знают все, интересующиеся темой, на VMworld был анонсировано и тут же выложено обновление для ESXi от 2021-10-05/ 18644231, одновременно с vCenter Server 7.0 Update 3 (7.0.3.00000). Обновление ESXi было выложено, потом убрано со скачивания, затем снова выложено в том же виде. По старой традиции VMware убирать странное и делать вид что ничего не было (что уже было не один раз с HCL) – из VMware ESXi 7.0 Update 3 Release Notes – ждем, когда из RN пропадут строки типа:
«VMFS block allocation issue might cause application data loss
Due to a rare VMFS block allocation issue, you might see a discrepancy between the scheduled and actually allocated blocks for a VMFS file. As a result, you might see some application data loss.
Workaround: None»
Совсем недавно там было еще и другое, а теперь нет:
«Virtual machines on a vSAN cluster with enabled NSX-T and a converged vSphere Distributed Switch (CVDS) in a VLAN transport zone cannot power on after a power off.
If a secondary site is 95% disk full and VMs are powered off before simulating a secondary site failure, during recovery some of the virtual machines fail to power on. As a result, virtual machines become unresponsive. The issue occurs regardless if site recovery includes adding disks or ESXi hosts or CPU capacity.
Workaround: Select the virtual machines that do not power on and change the network to VM Network from Edit Settings on the VM context menu.
ESXI hosts might fail with a purple diagnostic screen with an error Assert at bora/modules/vmkernel/vmfs/fs6Journal.c:835.
In rare cases, for example when running SESparse tests, the number of locks per transaction in a VMFS datastore might exceed the limit of 50 for the J6_MAX_TXN_LOCKACTIONS parameter. As a result, ESXi hosts might fail with a purple diagnostic screen with an error Assert at bora/modules/vmkernel/vmfs/fs6Journal.c:835.
Workaround: None.»
У VMware vCenter Server 7.0 Update 3 Release Notes ничего особо в глаза не бросилось, но там самое интересное в релиз могло и не попасть, потому что скрыто за строчкой Known Issues from Prior Releases.
«VM might lose Ethernet traffic after hot-add, hot-remove or storage vMotion.
A VM might stop receiving Ethernet traffic after a hot-add, hot-remove or storage vMotion. This issue affects VMs where the uplink of the VNIC has SR-IOV enabled. PVRDMA virtual NIC exhibits this issue when the uplink of the virtual network is a Mellanox RDMA capable NIC and RDMA namespaces are configured.
Workaround: You can hot-remove and hot-add the affected Ethernet NICs of the VM to restore traffic. On Linux guest operating systems, restarting the network might also resolve the issue. If these workarounds have no effect, you can reboot the VM to restore network connectivity.»
С чем столкнулись коллеги в ESXi
Для Dell — ESXi 7.0U3 upgrade fails with «Expected 1 component, found 2″(reddit).
Особенно хорошо и приятно выглядят строки: «I am on the phone with Vmware right now actually with a issue that relates back to this VIB error, and they haven’t got a clue how to resolve it.»
Пишут, что схожая проблема есть и на HPE.
У Huawei с обновлением тоже не все хорошо – обновление не устанавливается через vSphere Lifecycle Manager (VLM), ставится ли через ISO/Zip– тоже предмет отдельного разговора. Может и не ставиться без некоторых ручных движений.
С чем столкнулись коллеги в vCenter
На этот раз в vCenter сломали часть VLM, отвечающую за AD. Как следствие –
«Authentication failed, Lifecycle Manager server could not be contacted», Access to Lifecycle Manager fails in vCenter 7.0 Update 3 when logged in with an Active Directory account (KB85962) – но тут хотя бы есть решение, As a workaround you can login using an account from the SSO-internal vsphere.local domain, for example administrator@vsphere.local, to access the LifeCycle Manager.»
В vSphere 7.0u2 как сломали sftp, так пока и не починили, File-based Backups via SFTP in vCenter 7.0 Update 2d failing with «General system error reported by backup server» (KB85966).
Кроме того, до меня дошли пока не подтвержденные СЛУХИ, что в vSphere 7.0u3 сломали и SMB, по крайней мере, в части Windows SMB. Про Linux – идет проверка. Поскольку официального kb и решения пока нет, то получение решения, если у вас такая проблема, предполагается через техподдержку.
Взаимодействие vCenter 7.0 U3 с старыми ESXi
Как пишут в VMware Interoperability Matrix, VMware vCenter Server 7.0 U3 должен работать с ESXi 6.5 U1 / U2 / U3. На практике не все так гладко – например, установка свежайшего ESXi 6.5 October 2021 Patch от 2021-10-12 за номером 18678235 идет задумчиво, с ошибками то на stage, то на задумывающемся на непонятное время pre-check.