HelloI encounter an error when I try to open my Windows XP virtual machine. VMPlayer say me that 'the virtual machine is busy', but there aren't others virtual machines that are already running.
I try to find a fix on google, but it seams that usually this bug is related on the file /etc/vmware/not_configured. This is not my case, because I haven't this file.
I'm running Arch 32-bit with the official Arch kernel 3.0. I already patched my VMPlayer with this solution that I've found on the wiki:
I've VMware Player 3.1.2 running in Arch 64 bit + Openbox, with kernel 2.6.36 (from testing repo). I was able to patch vmplayer for the kernel but trying to run the Windows guest I get 'the virtual machine is busy'.
Just guessing but i would try
1. exit player and rerun it
2. exit vm player and try with vmware workstation and see if that fixes it
3. check for .lck (lock) files lingering in the virtual machine directory
Point is the only time i had a similar problem, was when exiting xorg or rebooting and forgetting to turn off my VMs. But unfortunately i don't remember if that's the exact error message that would pop-up.
Well, I had vmware player installed prior to updating the kernel to 2.6.36. I then ran the patch which allowed me to install the modules but the 'virtual machine is busy' problem appeared. I reinstalled vmware player, rebooted, no change. Yes, all modules are properly loaded as far as I can see.
I'm still running 2.6.35.
Usually when you upgrade your kernel (+kernel-headers) what happens is this:
When you reboot and run vmware/player it will detect that the vmware modules are built with an older kernel and will automatically rebuilt them and load them. I've never had this fail. While i had to use the patch described in the wiki the very first time i installed vmware, i'm not sure this is a step that needs to be repeated on subsequent kernel upgrages. I think i already upgraded my kernel once before and didn't have to repeat the patch procedure. The sources may already be present+patched and they are just recompiled for the new kernel. Again my memory may be failing me though. You will probably need to re-apply the patch when upgrading to a newer version of Vmware though (Unless this is fixed in newer versions of course).
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
I've got a virtual machine running on a server that I can't stop or reboot - I can't log onto it anymore and I can't stop it using the VMware server console. There are other VM's running so rebooting the host is out of the question. Is there any other way of forcing one machine to stop?
In some cases you may not be able to suspend, or for that matter take any of the "Power" actions on the VM. You may also already have multiple VMs up and running. Use this process to identify the correct PID to kill.
Switch to the Performance tab and start the "Resource Monitor". Expand the "Disk Activity" panel. Sort the "File" column. Look for the appropriate vmdk file for the VM you want to kill. The "Image" column will have the "vmware-vmx" process listed. Note the PID.
The esxcli command can be used locally or remotely to power off a virtual machine running on ESXi 5.x. For more information, see the esxcli vm Commands section of the vSphere Command-Line Interface Reference.
1. Fault Tolerant Guest Virtual Machines cannot currently be protected while in a Fault Tolerant configuration. This is due to the inability to snapshot a Fault Tolerant virtual machine and is a current limitation of VMware.
5. The presence of the VMware Tools Filesystem Sync Driver will cause this error because it will try to flush I/O at the same time the Remote Agent is trying to quiesce the file system and writers. This causes the VMware Tools service to hang, causing the WMI writer to fail, and the VSS service to crash.
7. When ESX hosts are clustered and vMotion is in use, if the virtual machines are selected by the ESX clustered node then this error can be received when the virtual machine is moved to be another ESX host of the cluster. This is because the virtual machine is no longer available through the selection that was made at the time the job was created.
8. A virtual machine with insufficient or 0 free space will also generate this error.
9. Check to see if the ESX server is listed as "Not responding" in the VMware Infrastructure Client or if the virtual machines hosted on that server are listed as "Disconnected."
2. Edit the job selection list and remove the old machine name, reselect the VM's in their current location with their current name, or move the VMs back to original location:
a. Open vCenter and select "Inventory > VM and Templates > Discovered Virtual Machine (or other folder)
b. Drag and drop the VMs to the original location
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.
VMware Workstation is a professional virtualization solution that allows you to do a lot of things and is able to manage many virtual machines at the same time (if the resources of the host PC allow it).
However, in rare cases (and especially when you edit manually some settings in the vmx files), VMware Workstation can become unstable and arrive in a state where you will not be able to access or close some virtual machines.
When you want to access it from VMware Workstation, a "This virtual machine appears to be in use" warning is displayed.
VMware Workstation offers you to obtain the rights on it by clicking on : Take Ownership.
If it's too late, you may not be able to force the virtual machine to shutdown from VMware Workstation.
Indeed, in this case, we wanted to shut down Windows properly by sending the Windows shutdown ACPI signal from VMware Workstation (via the "Shut Down Guest" option).
The problem is that the virtual machine never stopped, and because the virtual machine was shut down, no more options were available for this virtual machine.
Even when you want to close VMware Workstation to force the virtual machine to shut down, it will not work because VMware Workstation will display this warning : Virtual machine is busy.
The only problem is that you can't know which instance of the "vmware-vmx.exe" process corresponds to which virtual machine.
For security, you will have to shut down all possible virtual machines before killing this process or processes. Otherwise, you risk cutting off a virtual machine that was still running correctly.
Like magic, the virtual machine will be considered shut down by VMware Workstation.
Nevertheless, don't forget that the sudden shutdown of the "vmware-vmx.exe" process only allows you to recover your hand on the management of the host PC.
Indeed, by killing the "vmware-vmx.exe" process, the host PC will become unstable because of the information left in its RAM.
This may result in a slower shutdown of your host PC when you shut down Windows this time.
Once the host PC is shutdown and then power on again (and not with an automatic restart from Windows), the RAM will be correct again.
On our InformatiWeb.net website, we talked about the Panda USB Vaccine program that automatically vaccinate USB keys that you connect to your computer to prevent a virus on a USB key infect your physical PC.
When at least 1 virtual machine is running with VMware Workstation, if you plug an USB key on your physical PC, VMware Workstation and the currently powered virtual machine will be freezers.
Which is very problematic.
The problem is that when virtual machines run on VMware Workstation on your PC, there is a good chance that your PC (including VMware Workstation and the "Computer Management" console) will start blocking (freezing).
It's pretty annoying, but be aware that this bug only occurs if virtual machines are running when you want to manage physical PC disks.
If no virtual machine is currently running, disk management will be possible without any problem.
As mentioned above, you will not be able to plug an USB 3 key into an USB 3 port on the host PC and pass it to a virtual machine using version 2.0 or lower of the USB controller.
In this case, an error will be displayed :
To solve this problem, simply plug your USB key into a USB 2.0 port on your host PC.
Or change the version of the virtual machine's USB controller to USB 3.0 if you want to connect it to a USB 3.0 port on your host PC.
If you plug an USB 3.0 key or any other USB storage medium (such as an external hard drive) to an USB 2.0 port on your host PC, this message will be displayed on the host PC where VMware Workstation is installed.
VirtualMachine extends the ManagedEntity type because virtual machines are part of a virtual infrastructure inventory. The parent of a virtual machine must be a folder, and a virtual machine has no children. Destroying a virtual machine disposes of all associated storage, including the virtual disks. To remove a virtual machine while retaining its virtual disk storage, a client must remove the virtual disks from the virtual machine before destroying it. Properties
This property is set when a virtual machine is created or when the ReconfigVM_Task method is called. The virtual machine configuration is not guaranteed to be available. For example, the configuration information would be unavailable if the server is unable to access the virtual machine files on disk, and is often also unavailable during the initial phases of virtual machine creation.
datastore* PManagedObjectReference[]
to a Datastore[]
3a8082e126