Yrurtj

I would like to determine the name of a QEMU VM I started with:

qemu-system-x86_64 -m 4096 -smp 1 

  -net user -net nic,model=virtio -boot menu=on 

  -drive file=guixsd-usb-install-0.13.0.x86_64-linux.img 

-drive file=guixsd.img

(per the GuixSD VM installation guide). The reason for my desire to determine the VM's name is so that I can save its machine state (similarly to how one can for a VirtualBox VM) using the savevm command. I have tried using:

virsh -c qemu:///system list

but this returns:

 Id    Name                           State

----------------------------------------------------

likewise running:

ps -ef | grep qemu-system-x86_64

(per this AskUbuntu answer) isn't helpful because of the command I used to start the VM. If it is somehow relevant I am running Gentoo Linux as my host OS.

virsh is the CLI tool to operate the libvirt virtualisation management framework. In that framework, you would define virtual machines using any of the hypervisor supported by libvirt including qemu, xen, virtualbox via the management interface.

libvirt provides with a level of abstraction above things like qemu. With it, you would not start qemu directly. Instead libvirt would start qemu with some special options that allows to interact with qemu.

For instance, on my system, libvirt started qemu with those parameters for one it its VMs:

qemu-system-x86_64 -enable-kvm -name freebsd11.0 -S -machine pc-i440fx-wily,accel=kvm,usb=off -cpu Nehalem -m 1536 -realtime mlock=off -smp 3,sockets=3,cores=1,threads=1 -uuid 82f3448e-2767-46b1-a7d1-7072184ef924 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-freebsd11.0/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/chazelas/Downloads/FreeBSD-11.0-RC1-amd64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:11:8a:53,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on

Most of that is specification of the virtual hardware of the virtual machine, but you also see:

-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-freebsd11.0/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control

Which specifies a channel with which libvirt can interact with qemu (using some JSON-based machine protocol)

But you wouldn't be using that directly. You would issue virsh commands like virsh shutdown. virsh would transmit those to the libvirtd daemon which in turn would translate it to qemu specific instructions using that channel.

In your case, though, you're not using libvirt. You've not defined a VM using virt-manager or virt-install (or virsh define/create). Instead you've started qemu manually by yourself.

libvirt, if it's installed has no knowledge of that VM. So there's no point trying to use virsh to interact with it.

The way you've started qemu, you've not specified any particular monitor channel to interact with it, so you'll get the default.

By default, you'll typically get the SDL graphics console.

In it, you can type Ctrl+Alt+2 to get the human monitor interface. That's a command line interface. You'll see a

 (qemu) 

prompt where you can enter commands. Try help for a summary.

If you had given a name to your VM with -name, you'd be able to retrieve it with the info name command there.

That's where you'd run your savevm qemu command. But to use the savevm command, AFAIK, you have to have at least one qcow2 disk image attached to the VM which doesn't seem to be your case.

To suspend and save the state of the VM, you could do (at the (qemu) prompt):

migrate "exec:gzip>/path/to/savedstate.gz"

Which would suspend the VM and save the compressed state to a file. And then, you can quit and later bring back the VM from that saved state by adding a -incoming 'exec:gunzip</path/to/savestate.gz' to your qemu-system command line.

There's a whole lot of things you can do if you know qemu well, but if you want to make your life easier, you'd probably use management wrappers around qemu like libvirt.