Yep, the problem afaict is still here ..
I use the following,
Hypervisor:
Debian amd64 + kvm
(qemu-system-x86:
Installed: 2.1+dfsg-5
Candidate: 2.1+dfsg-5
Version table:
*** 2.1+dfsg-5 0
500 http://debian.bhs.mirrors.ovh.net/debian/ jessie/main amd64 )
VM:
Jessie amd64 testing (
the iso I'm using is
debian-jessie-DI-b2-amd64-CD-1.iso 66dfc5ffe9a26f4012ca2e1bd2818fbb
)
(fwiw a prior iso was used when I originally made the report)
The startup of the kvm is initiated like this ->
qemu-system-x86_64 -machine type=pc,accel=kvm -cpu kvm64 -m $RAM $HDA
$USOCKET $NICVIRTIO
RAM=256
HDA="-hda /path/t1_jessie.raw.bin" (the more ideal would be to use vda
drive but it's more gruesome->
eg, VDA="-drive
if=none,id=drive0,cache=none,aio=native,format=raw,file=${path_to_VM_image}
-device virtio-blk,drive=drive0,scsi=off,config-wce=off,x-data-plane=on"
)
MACADDRESS="54:52:00:00:01:01" (optional, you don' t need to use the
mac= but if you're using network then I recommend it since reboots will
randomize the macaddress voiding any setup in the interfaces file.
new macaddresses get stored in the VM's
-> /etc/udev/rules.d/70-persistent-net.rules
So if you need to revert any saved changes, you can delete entries from
here, set the mac= to the qemu command and expect "eth0" to be mapped
correctly on the next reboot.
)
TAPNUM="tapt1n1" (optional, can use "-net none" instead if not needing
any network)
..and some network (which is imho is lacking howto online so I'll throw
it in a quick smack)
Networking (feel free to skim this if you don't need this)
=======================
ip tuntap device -->
NICVIRTIO="-device virtio-net-pci,mac=${MACADDRESS},netdev=vmt1n1
-netdev type=tap,id=vmt1n1,ifname=${TAPNUM},script=no,downscript=no"
(tapt1n1 is a tuntap, can be created with
ip tuntap add dev tapt1n1 mode tap user <user>
user= the user running the kvm instance
, and then "ip tuntap set tapt1n1 up"
Over here I've add tuntap to an ovs bridge which is linked to a wire
network. Simply adding tapt1n1 to the ovs switch, here I call my switch sw1
ovs-vsctl add-port sw1 tapt1n1
note: on "reboot" there'll be a mismatch, .. and there's a current bug
for ovs to auto-add devices properly, -> ovs-vsctl del-port sw1 tapt1n1
and the readd it manually later
A very great resource quick 101 on how to do this->
https://www.youtube.com/watch?v=rYW7kQRyUvA
macvtap device->>
The difference with this one is to use fd= and then 3<>/dev/tapNum
with the qemu command
^ If you do not want to use ovs, brctl, or vde for creating networking
connectivity, then there's something better--> you can easily use
macvtaps directly on eth0 of the hypervisor, ... but a few caveats
the:-> these "tap" devices passed to the qemu command are a bit tricky,
and the hypervisor should be using the latest kernel and qemu, and
iproute2 package
NICVIRTIO="-device virtio-net-pci,mac=${MACADDRESS},netdev=vmt1 -netdev
type=tap,id=vmt1,fd=3
note, fd= "3" , which is the same "3" used with <>/dev/tap101
..then at the end of the qemu command ->
qemu <params> $NICVIRTIO 3<>/dev/tap101
(if this is set incorrectly, the qemu instance will stall on bootup
and the qemu process needs to be killed)
For creating the macvtap device, one can prefix "101" with the ip
creation command (or can peruse it from /proc as with an bash expand
variable as calling the kvm instance.. I prefer to use a prefix on
creation time)
ip link add link eth0 name mac0nic1 index 101 type macvtap
.. you need to specify the same mac address for macvtap as you do inside
the VM
ip link set mac0nic1 address 54:52:00:00:01:01
ip link set up
.. I can't recall I think you also might need to set the same IP address
as the internal VM.
^ Not documented well online anywhere.
Anyways you probably skimmed all this networking part which is fine, but
for anyone wanting a setup without having to use
1) Libvirt
2) Crazy bridges..
^ Can all be done with just a macvtap directly on eth0.. It's fast and
simple but my understanding one should be using the latest available
kernel/kvm/iproute2 for it to work as it should..
The reason why I mention these details is because it is not well
documented.. and actually tricky. At the very least the "mac address"
(unlike tuntap devices) has to match the same as in the VM. "Macvtaps"
are special but you want something that should work without too much
worry of setting up switches getting in the way.
If you don't use a network interface, simply pass "-net none" to the
qemu command.
===========================
..........
Now here is the soft ACPI shutdown "event" that I use from outside the VM:
-> With kvm, largely not well explained on its FAQ, is you can
initiate kvm console commands through a console connection... socat,
unixterm, or vdeterm can be used to connect to the unix socket.
The unix monitoring socket for kvm console commands is created with the
-monitor param (I reference this as USOCKET=)
" -monitor dev
* Redirect the monitor to host device dev (same devices as the
serial port). The default device is "vc" in graphical mode and "stdio"
in non graphical mode. Use "-monitor none" to disable the
default monitor."
USOCKET="-monitor unix:/path/t1.socket,server,nowait -daemonize"
then to connect to it,
"socat UNIX-CONNECT:<path to socket file> -"
(be sure to use the minus sign and hit enter, substitute the socket path)
or vdeterm/unixterm <socket file> with same effect
From there you'll get a prompt
"QEMU 2.1.2 monitor - type 'help' for more information
(qemu)"
commands can then be issued with it such as
"help"
"system_powerdown" <<< does the soft acpi shutdown
"q" or "quit" <<< this does a pulling of the power plug and is not the
one to use (essentially a direct kill of the qemu process)
So what works?
A quick overview as I can assure again I can replicate this problem.
-> "system_powerdown" from the KVM console which I call "outside" the
VM actually shuts down the VM entirely.(the VM then shutsdown and closes
the qemu window on its own)
.. compare this to
-> "halt" issued inside the VM which leaves the "qemu window" in an open
state with the frozen text message "[<time>] Reboot: System halted"
In order to close it, the window can be closed by clicking its
top-right 'X' control, or can do "quit" in the kvm console.
Now I first noticed this problem on a "remote" hypervisor which I have
no physical access to and it is like having "-display none" but I have
been able to visually verify this problem by using "-spice" and
tunnelling that via ssh.. I get a visual display of the VM and the same
frozen halted message. (not to delineate, spice is basically just a vnc
thing.. and as you know with Virtualization the "remote view" is against
the "process" of the Virtualization application and not to an "internal"
X instance inside the VM)
I admit to use just qemu without any helper libvirt shell commands is
gruesome.. so feel free to use a few variables to your disposal.. (You
don't need to use everything I mentioned like I have set nor do I
believe using optimized virtio param settings makes a different) but
basically it is just
1 ) "-monitor " and then
2) attach that unix socket to socat/vdeterm/unixterm to call
"system_powerdown"..
It's actually pretty easy to test.. but takes a bit of getting used to
knowing how to set this up manually.
==========
Here's a quick template,
mkdir ~/kvm_t1
cd ~/kvm_t1
fallocate -l 4294967296 t1_jessie.raw.bin
as root for creating the macvtap (no need for fussy bridge setups)
,
ip link add link eth0 name mymacvtap index 101 type macvtap mode bridge
ip link set mymacvtap address 54:52:00:00:01:01
(try not to use an index number under 20, as these tend to be already
used by the bootup system for lo, and eth0)
ip link set mymacvtap up
and done. No further bridge setup messes. But if I'm correct you should
be using the latest available "iproute2", kernel, and qemu for macvtaps
to work properly.
All that's needed since root was used, and there's no permanent rule
setting or any wizards helping to sort the user permissions.. If running
the kvm as userX, give him permissions to /dev/tap101 as
chgrp userX /dev/tap101 , and chmod g=rw /dev/tap101
The only reference now is to use fd=3 and 3<>/dev/tap101 with the qemu
command.
Be sure to issue "modprobe kvm" (or even kvm-intel or kvm-amd) prior to
starting the VM if you want acceleration
t1kvm.sh startup script
-------
(if need be full paths can be used in place for the items at HDA and
USOCKET.. I'll make it simple by having the script to be called by
entering the containing folder and issuing ./t1kvm.sh )
#!/bin/sh
RAM=256
HDA="-hda t1_jessie.raw.bin"
MACADDRESS="54:52:00:00:01:01"
USOCKET="-monitor unix:t1.socket,server,nowait -daemonize"
NICVIRTIO="-device virtio-net-pci,mac=${MACADDRESS},netdev=mynic -netdev
type=tap,id=mynic,fd=3"
qemu-system-x86_64 -machine type=pc,accel=kvm -cpu kvm64 -m $RAM $HDA
$USOCKET $NICVIRTIO 3<>/dev/tap101
and done.
What's needed for connecting to the monitoring socket socat, vdeterm or
unixterm to perform the acpi shutdown
"socat UNIX-CONNECT:t1.socket -<enter>"
(unixterm 1.socket<enter> is actually, it can be installed from the
package vde2)
now that there's the qemu() prompt, simply type
"system_powerdown" and watch the qemu window
If there's a stall message, simply typing "q" does a hard power-off of
the kvm or "kill" the process by clicking 'X' on the topright of the
qemu window or kill -9 the process number. (A proper and "full"
successful shutdown will close the qemu window and return the qemu()
prompt back to bash.)
It's easy to setup as you can see, simply copy and paste the
instructions and you will see the acpi shutdown fails..
..
A Cd-rom iso can be initiated to this if needs be->
CDROM="-cdrom debian.iso"
BOOTPRIO="-boot dc" (d is for cdrom before the harddrive)
qemu-system-x86_64 -machine type=pc,accel=kvm -cpu kvm64 -m $RAM
$BOOTPRIO $CDROM $HDA $USOCKET $NICVIRTIO 3<>/dev/tap101
thanks for taking a jab at this, hopefully you or someone can verify why
this is happening because it is rather an odd case.. Also I had to go at
lengths at this because this is not very well documented online.
For one, there will be a "VM stall" on bootup if the permission is not
setup accordingly on the macvtap device for the running kvm user.
Another thing is you don't want to rush things because -monitor is a
bitch.->> if you accidentally (it happened to me once XD) specify a VM
image with -monitor, the kvm instance will immediately wipe that
multi-gigabyte to bazeero. Usually not a big deal, but is so if you use
kvm alot from the command line.
This is largely not the way most people are using kvm, but one can
definitely cut out all the bullshit with libvirt which isn't needed at
all. So if you're testing this, you don't even need virtsh.. just socat
to the socket and issue that acpi shutdown..
hopefully this bug can be resolved sometime in the near future now that
I provided details as much as possible to replicate the similar setup
I'm using...
What will take time is if you ever need to throw in a network connection
to the kvm. The fastest/easiest that I know is the one I explained with
the macvtap, but I would recommend going for ovs/+tuntap for the longterm
thanks for looking into this..
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
