Dixi quod…
> To add insult to injury, it didn’t even shut it down cleanly:
>
> tglase@tglase:~ $ virsh -c qemu:///system list
> Id Name State
> ----------------------------
> 3 MirBSD in shutdown
>
>
> “virsh destroy 3” to the “rescue”…
Oh, it gets worse. Trying to restart the VM after that:
tglase@tglase:~ $ virsh -c qemu:///system start MirBSD
error: Failed to start domain MirBSD
error: internal error: qemu unexpectedly closed the monitor:
2020-03-19T19:18:11.146627Z qemu-system-x86_64: -device
ide-hd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0,bootindex=1,write-cache=on:
Failed to get "write" lock
Is another process using the image [/dev/vg-tglase/mirbsd]?
1|tglase@tglase:~ $ ps ax | fgrep qemu
12262 pts/5 S+ 0:00 grep -F qemu
14125 ? Sl 752:48 /usr/bin/qemu-system-x86_64 -enable-kvm -name
guest=MirBSD,debug-threads=on -S -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-MirBSD/master-key.aes
-machine pc-i440fx-2.5,accel=kvm,usb=off,dump-guest-core=off -m 1024 -realtime
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
b0994f54-15e8-bb58-2f8f-1460fc81ec6b -no-user-config -nodefaults -chardev
socket,id=charmonitor,fd=27,server,nowait -mon
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot
strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/dev/vg-tglase/mirbsd,format=raw,if=none,id=drive-ide0-0-0,cache=none,aio=native
-device
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1,write-cache=on
-netdev tap,fd=25,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=52:54:00:49:f7:4f,bus=pci.0,addr=0x3 -chardev
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc
127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -object
rng-random,id=objrng0,filename=/dev/urandom -device
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x5 -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg
timestamp=on
It’s dead in virt-manager, but connecting via VNC might be
possible — first find out the port…
tglase@tglase:~ $ sudo netstat -anp | fgrep 14125
tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN
14125/qemu-system-x
… then connect to it:
tglase@tglase-nb:~ $ vncviewer -via tglase ::5900
Incidentally, at this point, the guest networking was already dead,
but connecting to it allowed me to proceed in shutting it down cleanly,
followed by sudo-killing the qemu process.
Thankfully, after that, starting it worked, and things work again,
including networking.
My initial assertion that it’s not okay to just kill running VMs stands.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
**********
Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
**********
