-qmp option sends SIGINT to qemu - qemu

I use following script to start qemu with qmp
qmu-system-x86_64\
-nographic \
--enable-kvm \
...
-qmp tcp:127.0.0.1:5555,server,nowait
When I hit CTRL-C inside the guest OS, I want my running process to be stopped without terminating the OS itself.
However, qmp option terminates my entire qemu when I hit CTRL-C with following message.
qemu-system-x86_64: terminating on signal 2
Without qmp option, it works as I desired.(kill process running inside guest OS, without killing guest itself).
Is there any way to use qmp option without killing qemu with CTRL-C?

Is there any way to use qmp option without killing qemu with CTRL-C?
Adding -serial mon:stdio to your command line should help.

Related

libvirt: how to prevent "accel=kvm"

First, some background:
I suppose I've found a bug with KVM, at least on my system.
When I try to install Windows XP via virt-manager, the installer aborts/reboots.
But if I run a raw qemu-system-i386 command (see below), it succeeds.
From looking at the logs in /var/log/libvirt/qemu/..., the key difference is the "accel=kvm" argument (equivalent to -enable-kvm).
So, narrowing it down, this command succeeds:
qemu-system-i386 \
-m 512 \
-usb \
-cdrom path/to/WinXP_CD.iso \
-boot d \
"$image"
But this next command results in an infinite series of reboots. The XP installer starts, but after scanning the system, just reboots rather than proceeding:
qemu-system-i386 \
-enable-kvm \
-m 512 \
-usb \
-cdrom path/to/WinXP_CD.iso \
-boot d \
"$image"
Perhaps you don't believe I have KVM working properly on my system.
But, I can install other OSes (eg: FreeBSD) using KVM just fine. This seems to be XP-specific.
So now, my questions:
How do I force libvirt to NOT use KVM for a chosen VM? Ideally via virt-manager, but I'm fine with virsh too.
I imagine somewhere in the mess of XML is some setting, but I'm not terribly familiar.
aside: any idea where I should log this bug? Against KVM? Libvirt? QEMU?
Well, I managed to hack around this, but I'm sure there's a more pretty way.
Basically, that -enable-kvm option corresponds to the type="kvm" value in your domain XML file. See libvirt documentation.
But there seems to be no way to change this from virt-manager. I'm not familiar enough with virsh yet to do it that way either. So, I just manually edited my XML file like so:
$ sudoedit /etc/libvirt/qemu/myxp.xml
I did this while virt-manager was closed.
When I opened it, the setting did not seem to stick. For some reason, I seemed to need to run:
$ sudo virsh define /etc/libvirt/qemu/myxp.xml
to get it to stick.
Anyway, after that little dance, then in virt-manager, in the `Overview' tab for my VM, it says "Hypervisor: QEMU TCG", where it had "KVM" before.
And now, the XP installer works!
Again, probably a better way, but good enough for now.
Presumably, performance will be poorer with KVM disabled. I still don't know who to send a bug, or whether this is a QEMU or KVM issue, at its core.
You can change
<domain type="kvm">
to
<domain type="qemu">
as as stated in the documentation.
To edit xml of VM in virt-manager you should activate xml editing in parameters and press "xml" tab.

How to redirect QEMU output to Windows cmd console?

I am trying to use the qemu-system-arm.exe on Windows 10 to simulate an ARM environment.
I use below command to disable serial and graphic:
qemu-system-arm -machine versatilepb -kernel t.bin -nographic -serial
none
I set the -serial none because my t.bin doesn't touch the serial port of the QEMU virtual machine. So there should be no data on the serial line.
But when I type commands in the (qemu) prompt, it contains many unexpected control characters. Though the command seems still working.
QEMU 4.0.95 monitor - type 'help' for more information
(qemu) h[K[Dhe[K[D[Dhel[K[D[D[Dhelp[K
I also tried to use com0com to create a pair of virtual serial ports. And connect them as below.
But both ends show nothing as I type commands. I guess it was due to incorrect baud rate. So I tried a few but still no luck. As said above, I think the serial line is quite because there's serial communication happening.
I launched qemu the same way on Linux, the (qemu) prompt works perfect. Only Windows has such mess characters.
So how to redirect (qemu) output to Windows cmd console properly? I just want to check some machine states.
(Well, this is just a work around...)
I launch exactly the same command within a Cygwin shell, the mess characters disappear now...
ANSI support is missing in the Windows command console (before Windows 10 Terminal app).
Your com0com solution works just fine, at least for me (QEMU on Windows 8.1 emulating Debian MIPS).
All I had to do was to add the following, and then connect with PuTTY to COM9:
-chardev tty,path=COM8,id=hostcom8 -device pci-serial,chardev=hostcom8 -append "console=ttyS2" (I had ttyS0 and ttyS1 virtual serial ports)

Using socat to access X remotely

I have a remote server on which I want to launch some gui applications inside a network namespace I have already setup. I am using socat to forward the x session.
socat exec:'ssh {REMOTE_HOST} rm -rf /tmp/.X11-unix/X1; socat -d -d -d -d unix-l\:/tmp/.X11-unix/X1111 -' unix:/tmp/.X11-unix/X0
However, if I try to launch an application like eog
DISPLAY=:1111 eog
It fails with the following message:
I No protocol specified
** (eog:9498): WARNING **: Could not open X display
Cannot open display:
Run 'eog --help' to see a full list of available command line options.
And socat exits immediately afters.
Well, it took a day but I figured a way to do it.
I ended up using Xpra to start an X-server at the remote server and attached to it in my local machine.
The socat approach worked too after running xhost + locally and adding the fork flag in the socat invocation at the remote server . However, it never worked consistently (There was as much chance the application to hang during launch as not). And it never worked with more complex applications like firefox. Stracing the apps pointed towards the applications hanging when trying to use dbus.

running beaglebone image on qemu : libusb error

I'mt trying to run beaglebone image on qemu following this tutorial. im using ubuntu 14.04 and installed qemu as shown in the tutorial
when ruining the command
qemu-system-arm -M beaglexm -drive if=sd,cache=writeback,file=Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img -clock unix -serial stdio -device usb-kbd -device usb-mouse -usb -device usb-net,netdev=mynet -netdev user,id=mynet
I got this error :
qemu-system-arm: symbol lookup error: qemu-system-arm: undefined symbol: libusb_get_port_numbers
I dont know if it's libusb version issue or what.
There is a similar bug report on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711589
I had the same message on my system. To solve it you have, as root, to link in the correct libusb.
sudo ln -sf /lib/x86_64-linux-gnu/libusb-1.0.so.0 /usr/local/lib/libusb-1.0.so.0
Start by running (YMMV on where the 'qemu' binaries are located):
ldd /usr/bin/qemu-system-arm
You should get a lot of output indicating what runtime libs Qemu needs and where the system is finding them. The fact that you are getting a 'missing symbol' error means that a shared library is on the system, it just isn't exporting the 'libusb_get_port_numbers' function signature.
If the above is true, then either A) your distro's 'libusb' packages don't export that function (it might have been deprecated) or B) you have some other 3rd party application that installed it's own 'libusb' (MPLABX does this, puts it in /usr/local/lib and symlinks back to /opt/microchip).
Without any more OS info etc, it's hard to help.

How can I flush GPU memory using CUDA (physical reset is unavailable)

My CUDA program crashed during execution, before memory was flushed. As a result, device memory remained occupied.
I'm running on a GTX 580, for which nvidia-smi --gpu-reset is not supported.
Placing cudaDeviceReset() in the beginning of the program is only affecting the current context created by the process and doesn't flush the memory allocated before it.
I'm accessing a Fedora server with that GPU remotely, so physical reset is quite complicated.
So, the question is - Is there any way to flush the device memory in this situation?
check what is using your GPU memory with
sudo fuser -v /dev/nvidia*
Your output will look something like this:
USER PID ACCESS COMMAND
/dev/nvidia0: root 1256 F...m Xorg
username 2057 F...m compiz
username 2759 F...m chrome
username 2777 F...m chrome
username 20450 F...m python
username 20699 F...m python
Then kill the PID that you no longer need on htop or with
sudo kill -9 PID.
In the example above, Pycharm was eating a lot of memory so I killed 20450 and 20699.
First type
nvidia-smi
then select the PID that you want to kill
sudo kill -9 PID
Although it should be unecessary to do this in anything other than exceptional circumstances, the recommended way to do this on linux hosts is to unload the nvidia driver by doing
$ rmmod nvidia
with suitable root privileges and then reloading it with
$ modprobe nvidia
If the machine is running X11, you will need to stop this manually beforehand, and restart it afterwards. The driver intialisation processes should eliminate any prior state on the device.
This answer has been assembled from comments and posted as a community wiki to get this question off the unanswered list for the CUDA tag
for the ones using python:
import torch, gc
gc.collect()
torch.cuda.empty_cache()
I also had the same problem, and I saw a good solution in quora, using
sudo kill -9 PID.
see https://www.quora.com/How-do-I-kill-all-the-computer-processes-shown-in-nvidia-smi
One can also use nvtop, which gives an interface very similar to htop, but showing your GPU(s) usage instead, with a nice graph.
You can also kill processes directly from here.
Here is a link to its Github : https://github.com/Syllo/nvtop
on macOS (/ OS X), if someone else is having trouble with the OS apparently leaking memory:
https://github.com/phvu/cuda-smi is useful for quickly checking free memory
Quitting applications seems to free the memory they use. Quit everything you don't need, or quit applications one-by-one to see how much memory they used.
If that doesn't cut it (quitting about 10 applications freed about 500MB / 15% for me), the biggest consumer by far is WindowServer. You can Force quit it, which will also kill all applications you have running and log you out. But it's a bit faster than a restart and got me back to 90% free memory on the cuda device.
For OS: UBUNTU 20.04
In the terminal type
nvtop
If the direct killing of consuming activity doesn't work then find and note the exact number of activity PID with most GPU usage.
sudo kill PID -number
If you have the problem that after killing one process the next starts (Comment)- like for example when you have a bash script that calls multiple python scripts and you want to kill them but can't find its PID you can use ps -ef where you'll find the PID of your "problematic" process and also its PPID (parent PID). Use kill PPID or kill -9 PPID or sudo kill PPID to stop the processes.
to kill all processess on GPU:
sudo fuser -v /dev/nvidia* -k
If all of this does not work, I found another answer here:
How to kill process on GPUs with PID in nvidia-smi using keyword?
nvidia-smi | grep 'python' | awk '{ print $X }' | xargs -n1 kill -9
Note that X (in the 'awk' expression) corresponds to the Xth column of your nvidia-smi command.
If your nvidia-smi command looks like this, you should then replace X by 5.
I just started a new terminal and closed the old one and it worked out pretty well for me.