Como determinar o nome de uma máquina virtual QEMU em execução?

1

Gostaria de determinar o nome de uma VM do QEMU com a qual comecei:

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

(de acordo com o Guia de instalação da VM do GuixSD ). A razão para o meu desejo de determinar o nome da VM é para que eu possa salvar seu estado da máquina (da mesma forma que se pode para uma VM do VirtualBox) usando o comando savevm . Eu tentei usar:

virsh -c qemu:///system list

mas isso retorna:

 Id    Name                           State
----------------------------------------------------

da mesma forma:

ps -ef | grep qemu-system-x86_64

(por esta resposta do AskUbuntu ) não é útil por causa do comando que usei para iniciar a VM. Se for de alguma forma relevante, estou executando o Gentoo Linux como meu SO host.

    
por Brenton Horne 23.05.2017 / 20:31

1 resposta

0

virsh é a ferramenta CLI para operar a estrutura de gerenciamento de libvirt virtualização. Nessa estrutura, você definiria máquinas virtuais usando qualquer um dos hipervisores com suporte de libvirt , incluindo qemu , xen , virtualbox por meio da interface de gerenciamento.

libvirt fornece um nível de abstração acima de coisas como qemu . Com ele, você não iniciaria qemu diretamente. Em vez disso, libvirt iniciaria qemu com algumas opções especiais que permitem interagir com qemu .

Por exemplo, no meu sistema, libvirt iniciou o qemu com esses parâmetros para um deles suas 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

A maior parte disso é a especificação do hardware virtual da máquina virtual, mas você também vê:

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

Que especifica um canal com o qual libvirt pode interagir com qemu (usando algum protocolo máquina baseado em JSON)

Mas você não estaria usando isso diretamente. Você emitiria virsh comandos como virsh shutdown . virsh os transmitiria ao daemon libvirtd , que por sua vez traduziria para qemu instruções específicas usando esse canal.

No seu caso, você não está usando libvirt . Você não definiu uma VM usando virt-manager ou virt-install (ou virsh define/create ). Em vez disso, você iniciou qemu manualmente por você mesmo.

libvirt , se estiver instalado, não tem conhecimento dessa VM. Então não adianta tentar usar virsh para interagir com ele.

A maneira como você iniciou qemu , você não especificou nenhum canal monitor específico para interagir com ele, então você obterá o padrão.

Por padrão, você normalmente terá o console gráfico SDL .

Nele, você pode digitar Ctrl + Alt + 2 para obter a interface do monitor humano . Essa é uma interface de linha de comando. Você verá um

 (qemu) 

avisa onde você pode inserir comandos. Experimente help para um resumo.

Se você tiver dado um nome à sua VM com -name , poderá recuperá-lo com o comando info name .

É aí que você executaria o comando savevm qemu. Mas para usar o comando savevm , AFAIK, você precisa ter pelo menos uma imagem de disco qcow2 anexada à VM, o que não parece ser o seu caso.

Para suspender e salvar o estado da VM, você poderia fazer (no prompt (qemu) ):

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

O que suspenderia a VM e salvaria o estado compactado em um arquivo. E, em seguida, você pode quit e, mais tarde, recuperar a VM desse estado salvo adicionando uma -incoming 'exec:gunzip</path/to/savestate.gz' à sua linha de comando qemu-system .

Há um monte de coisas que você pode fazer se você conhece qemu bem, mas se você quiser facilitar a sua vida, você provavelmente usaria wrappers de gerenciamento em torno do qemu como libvirt.

    
por 23.05.2017 / 22:29

Tags