VMWare Workstation won't suspend from command line - vmware

I'm trying to automate VMWare Desktop on Windows 7 to suspend all vm's before I do a backup job each night. I used to have a script that did this but I've noticed now that it won't suspend anymore with the same command that used to work.
If I do vmrun list I get a list of the running vms with no issue.
If I do vmrun suspend "V:\Virtual Machines\RICHARD-DEV\RICHARD-DEV.vmx" it just hangs and I have to kill the command with CTRL+C.
I've even tried a newer command using -T to specify it's workstation, ie vmrun -T ws suspend "V:\Virtual Machines\RICHARD-DEV\RICHARD-DEV.vmx" and still no love.
If I have the vm already stopped, I can issue vmrun start "V:\Virtual Machines\RICHARD-DEV\RICHARD-DEV.vmx" and it starts fine.
As well as the suspend command, the stop command also does not work. I'm running VMWare Workstation 11.1.3 build-3206955 on Windows 7.
Any ideas?
Update:
I installed latest VMWare Tools on the guest, as well as the latest Vix on the Host so everything should be up to date.
I can start a vm using vmrun with no problem using vmrun -T ws start <path to vmx> but the command doesn't come back to the command prompt, so I'm assuming it's not getting confirmation from the vm that it is now running.
If I cancel the 'start' command and now try and suspend I'm getting the same lack of communication from the guest. If I manually suspend the vm, once it's suspended I get an 'Error: vm is not running' and the 'suspend' command finally times out and comes back.
So, it looks to me like there is no communication from vmrun to the guest about what state it's in etc. Is there a way to debug the communication from the host to the guest using vmrun or other means? Are there ports I need open in the guest OS?

So, I never did get vmrun to work properly on my main system, although I did get it behave ok on my laptop so there is something weird happening on this machine. I also installed a trial of the latest VMWare 12 and the same thing happens.
As a workaround, I ended up changing the power management settings in my guest OS so that it would 'sleep' after 1 hr of inactivity. When this happens VMWare detects it and automatically suspends the guest which is really what I'm looking for. Not the most slick solution but it does manage to unlock the files I need to be backed up in a nightly backup.

Related

Can not find NVIDIA driver after stop and start a deep learning VM

[TL;DR] First, wait for a couple of minutes and check if the Nvidia driver starts to work properly. If not, stop and start the VM instance again.
I created a Deep Learning VM (Google Click to Deploy) with an A100 GPU. After stopping and starting the instance, when I run nvidia-smi, I got the following error message:
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
But if I type which nvidia-smi, I got
/usr/bin/nvidia-smi
It seems the driver is there but can not be used. Can someone suggest how to enable NVIDIA driver after stopping and starting a deep learning VM? The first time I created and opened the instance, the driver is automatically installed.
The system information is (using uname -m && cat /etc/*release):
x86_64
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
I tried the installation scripts from GCP. First run
curl https://raw.githubusercontent.com/GoogleCloudPlatform/compute-gpu-installation/main/linux/install_gpu_driver.py --output install_gpu_driver.py
And then run
sudo python3 install_gpu_driver.py
which gives the following message:
Executing: which nvidia-smi
/usr/bin/nvidia-smi
Already installed.
After posting the question, the Nvidia driver starts to work properly after waiting for a couple of minutes.
In the following days, I tried stopping/starting the VM instance multiple times. Sometimes nvidia-smi directly works, sometimes does not after >20 min waiting. My current best answer to this question is first waiting for several minutes. If nvidia-smi still does not work, stop and start the instance again.
What worked for me (not sure if it will go well to next starts) was to remove all drivers: sudo apt remove --purge '*nvidia*', and then force the installation with sudo python3 install_gpu_driver.py.
In the install_gpu_driver.py, change line 230 to return False inside of the check_driver_installed function. Then, run the script.
Who uses docker may face this error docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]] and have to reinstall the docker too. This thread helped me.

Google Cloud virtual instance: Chrome remote desktop indicates remote computer is offline, however Google Cloud Platform shows instance is running

I am running a virtual machine in Google Cloud. I have installed the default Debian OS, and configured the desktop environment for remote connection, as explained here: https://cloud.google.com/solutions/chrome-desktop-remote-on-compute-engine
I have been able to connect to the instance via Chrome Remote Desktop, however periodically I have the problem that the Remote Desktop says the vm instance is online, however if I try to connect to it I get:
Looking at the Google Cloud console, the instance is clearly running. Normally if I restart the instance the problem is solved, however I have processes running on the instance that I do not want to stop.
UPDATE:
Following the advice from Serhii Rohoza I ran
sudo systemctl status chrome-remote-desktop
The status looked normal, listing:
Active: active (exited) since...
I then ran
sudo systemctl restart chrome-remote-desktop
and this solved the problem, I could log into remote desktop again, but it seemed the VM instance had restarted, which is a big problem since I am running processes on it that should not shut down. I guess this is a problem to send to Google Cloud Services support.
UPDATE 2:
I'm still running into this problem. I normally have a Jupyter Notebook running on the VM - this Notebook must keep running. When I saw the message saying that the remote computer is offline, I logged in via ssh and checked if the Jupyter Notebook is running:
jupyter notebook list
This returned:
http://localhost:8888/?token=9110bf40789971b5e252a272e9497039b4f3b45e506348df :: /home/qgenixtech
So the Notebook was running. I then ran:
sudo systemctl restart chrome-remote-desktop
and after that again:
jupyter notebook list
and then it shows no Notebooks running. So the restart command closed down the Notebook (and also all other open windows on the desktop).
UPDATE 3:
I spoke to a support technician at Google. The problem is on the Remote Desktop side, not the virtual machine. According to the technician this is a known problem, by he didn't have a solution for it. He referred me to these two links from Google Support:
https://support.google.com/chrome/thread/10213547?hl=en
https://support.google.com/chrome/thread/3333421?hl=en
The next option for me is to look at something like X2go
To solve your issue you should follow documentation Troubleshooting and check status of the Chrome Remote Desktop service with command:
sudo systemctl status chrome-remote-desktop
and check log messages at /tmp/chrome_remote_desktop_DATE_TIME_*.
To investigate why your VM instance was restarted you should look for some clues at the logs:
Go to Compute Engine -> VM instances -> click on NAME_OF_YOUR_VM -> find section Logs -> click on Stackdriver Logging. More information you can find in the documentation Viewing logs (Classic)
Go to Compute Engine -> VM instances -> click on NAME_OF_YOUR_VM -> find section Logs -> click on Serial port 1 (console). More information in the documentation Viewing Serial Port Output
You can contact with Google Cloud Support as well.
In addition, have a look at the documentation Setting instance availability policies.
same issue. when checking logs i see:
2021-01-05 14:29:38,319:INFO:Starting Xvfb on display :20
xdpyinfo: unable to open display ":20".
2021-01-05 14:29:40,837:INFO:X server is active.
restarting service or even VM doesn't work.
i need to delete connection on "client" and re-auth with /headless link

Can I bring up the GUI for a Vagrant managed Virtual box while the box is running?

I know that I can configure my Vagrantfile to boot my machine with a GUI according to http://docs.vagrantup.com/v2/virtualbox/configuration.html with:
config.vm.provider "virtualbox" do |v|
v.gui = true
end
But if I've started a box headless, is there any way to bring up a GUI while the machine is running? Virtualbox provides the small preview, so I suspect it is possible but I haven't found any documentation on how to do this.
Edit: Terry pointed out that I can vagrant reload after changing the setting above to get a gui, but that reboots the box. I'm still hoping there's a easy way to enable the gui without a reboot.
There are 3 ways I've found to get a gui on a running headless machine if you can see it in the VirtualBox Manager:
You can suspend the machine (Close|Save State or vagrant suspend) and then start it again. When you restart it, you will see the GUI.
or, if you don't want to stop the machine at all:
You can go to display settings and enable the Remote Display Server while it's running (you may want to change the default port), and then use an RDP viewer (On Windows use Remote Desktop Connection) to access the GUI.
[Edit July 2015] With VirtualBox 5.0, click on the headless VM, choose "Show", and it will bring up the gui.
You'll have to do vagrant reload after enabling gui.
But there is a trick (a bit risky in my opinion)
1. save the state of the VM VBoxManage controlvm NAME_OR_UUID savestate
2. star vbox gui and resume
BTW: BTW: Why do you need GUI for Vagrant managed (headless) running VMs? If you prefer GUI to manage headless VMs, try phpVirtualBox.
From my experience with vagrant once you start completely headless there is no way to boot the GUI, you have to boot it on start with the line you mention above.
If it's running on VirtualBox (what vagrant typically uses) :
preface: you can't without (shortly) interrupting the VM! So you can't just open it for a running instance in VirtualBox.
You may find http://www.toptensoftware.com/VBoxHeadlessTray/ helpful, it has minor bugs if you ask me but nice to have to save what you can do ...
... On console: you might simply do what #terry-wang wrote:
suspend machine by VBoxManage controlvm <NAME_OR_UUID> savestate
restart with gui option VBoxManage startvm <NAME_OR_UUID> --type gui
alternative: start gui manager yourself as terry wrote
revert / make headless from gui: VBoxManage startvm <NAME_OR_UUID> --type headless
Update on VirtualBox 5: VirtualBox GUI has the function to start in Background nativly included now, so still the tool is a shortcut but not even more needed to not be forced using the console
I use:
VBoxManage startvm <NAME_OR_UUID> --type separate
The type separate is experimental according to the documents, but it seems to work in bringing up the GUI after the VM has already been started headless.

Virtualbox remote display updates remote as well as local screen

Folks,
I am running Virtualbox on Windows 7. The guest OS also is Windows 7.
I configured rdp connection at port 5000 (as stated in the documentation) and am able to connect to ip:5000 using Microsoft Remote Desktop client.
However, the problem is that the screen of the guest VM is simultaneously being shown on both, local as well as remote, windows.
Is there a way to just close the local window without shutting down the VM itself? Perhaps something similar to headless virtualbox on Linux.
Thank you in advance for your help.
Regards,
Peter
You can start a Virtualbox VM without GUI from the command line using:
VBoxHeadless --startvm [vmname]
There is also a section about running headless VMs in the Virtualbox manual: http://www.virtualbox.org/manual/ch07.html
Using the VBoxManage startvm command with the --type option is superior to VBoxHeadless as the former doesn't require the command prompt window to remain open (which largely defeats the purpose I think).
Below is and example of its output:
C:\>"C:\Program Files\Oracle\VirtualBox\VBoxManage" startvm "My Virtual Machine" --type headless
Waiting for VM "My Virtual Machine" to power on...
VM "My Virtual Machine" has been successfully started.
C:\>
Note that control is returned to the common prompt, allowing it to be closed without terminating the instance. The VM's status will also still be reported by the VirtualBox GUI.
The VBoxManage startvm command is documented in chapter 8 of the VirtualBox manual.

Vagrant reset my VM and now I am frightened I lost my work

I have a horrible situation and I hope you can help.
This morning, the terminal opened in my VM hanged, I tried to access Virtualbox and it went unresponsive. I killed Virtualbox manually and typed vagrant up. Vagrant (vagrant ssh) booted on a VM that pretty much seems the default one and I am terrified that all my work has been lost.
Typing vmboxmanage list vms shows:
wasp_1375609265" {29663113-786b-4b8a-adc8-2edecf06bcff}
which is the same UUID I find on the .vagrant file.
I am on a Mac OSX Montain Lion, the version of vagrant I am using is 1.0.6 and Virtualbox is 4.2.16.
Is there any way I can access the image at the previous state it had before I manually killed it? I can't believe that vagrant or Virtualbox purposely overwrote the image with a default one
It turned out that I am an idiot and the image was not lost. For some reasons Virtualbox saved it with a cryptic name and vagrant reverted to the default vagrant box wasp_32... when I run it again. I found the image I was looking for simply running all the *.vmdk I found under ~/VirtualBox VMs.
After that I followed the instructions I found here to make vagrant booting the correct image