Package: qemu
Version: 2.1+dfsg-7+b1
Severity: important
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these lines ***
Someone else reported this issue (see bug #760365), but one of the maintainers
dismissed the issue as user error, and closed that case.
Ideally, I'd prefer to reopen that case, so that anyone else who is tracking
this issue may easily find the info in one place.
Basically, I intended to run some tests in a KNOPPIX 7.4 liveCD environment,
because it's easy to setup, and the results are easily reproducible.
I've been working with qemu since 2003. My goal was to rebuild the linux
kernel (with a few additional options) within a qemu session (also running
KNOPPIX 7.4).
qemu-system-x86_64 (prior to that upgrade) used to run just fine with the
following options:
(_nm="calamansi"; sudo -b nice -n -10 kvm -m 400M -cpu
kvm64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3,+vmx -smp
4,sockets=2,cores=2,threads=2 -device pci-ohci -drive
if=ide,file=tmp/Downloads/KNOPPIX_V7.4.0DVD-2014-08-01-EN.iso,media=cdrom,aio=native,readonly=on,format=raw
-boot d -device virtio-net-pci,netdev=net0,mac=FE:ED:DE:AD:BE:EF -netdev
type=tap,id=net0,ifname=tap0,script=no,downscript=no -device
virtio-net-pci,netdev=net1,mac=FE:ED:DE:AD:10:01 -netdev
type=tap,id=net1,ifname=tap2,script=no,downscript=no -drive
if=virtio,file=tmp/tmp/hd.cdlit.5,id=myMacQemuHD,media=disk,aio=native -device
virtio-9p-pci,fsdev=MacSharedDir,mount_tag=MacSharedDir -fsdev
local,id=MacSharedDir,path=.,security_model=passthrough -usb -vga std
-localtime -enable-kvm -rtc base=localtime,clock=host -k en-us -name
${_nm},process=${_nm})
qemu-system-x86_64 runs fine with the following options:
(_nm="calamansi"; qemu-system-x86_64 -m 400M -cpu
qemu64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3,+vmx -smp
4,sockets=2,cores=2,threads=2 -device pci-ohci -drive
if=ide,file=/media/sdd1/ISOs/KNOPPIX_V7.4.0DVD-2014-08-01-EN.iso,media=cdrom,aio=native,readonly=on,format=raw
-boot d -usb -vga std -localtime -enable-kvm -rtc base=localtime,clock=host -k
en-us -name ${_nm},process=${_nm})
qemu-system-x86_64 fails to run with the following options:
(_nm="calamansi"; sudo -b nice -n -10 qemu-system-x86_64 -m 400M -cpu
qemu64,+lahf_lm,+popcnt,+sse4.2,+sse4.1,+ssse3,+vmx -smp
4,sockets=2,cores=2,threads=2 -device pci-ohci -drive
if=ide,file=/media/sdd1/ISOs/KNOPPIX_V7.4.0DVD-2014-08-01-EN.iso,media=cdrom,aio=native,readonly=on,format=raw
-boot d -usb -vga std -localtime -enable-kvm -rtc base=localtime,clock=host -k
en-us -name ${_nm},process=${_nm})
The difference between the working and failing invocations is that I invoke the
latter variant with 'sudo -b nice -n -10'. The primary reason why I invoke
qemu with sudo is becasue I ultimately need/want to configure my qemu network
using a tap/tun device. The secondary reason is because qemu won't allow a
non-root user to browse or access files in the subdirectories of the mountpoint
(even though I could access them just fine via ls, vi, etc).
BTW, tmp is a mount point for my home directory on another computer (a Mac
running OSX [connected via sshfs]). Here are the options that I use:
sshfs -o
ServerAliveInterval=15,allow_other,default_permissions,follow_symlinks,rw
myUID@myMacInternalIP: tmp
Here's the relevant part of my host env configuration that affects my qemu
session(s):
modprobe -a kvm tun dummy
modprobe kvm-intel nested=Y
modprobe nbd max_part=8
modprobe -a virtio virtio_pci virtio_ring virtio_net vhost_net
(for f in tap{0..1}; do openvpn --mktun --dev ${f} --user knoppix; done)
ifconfig dummy0 promisc 0.0.0.0 up
brctl addbr br0
for f in dummy0 tap0 tap1; do brctl addif br0 $f; done
ifconfig br0 192.168.0.21 netmask 255.255.255.0 up
brctl stp br0 off
sysctl net.ipv4.ip_forward=1
ip link set tap0 up; ip link set tap1 up
iptables -I INPUT 2 -i br0 -j ACCEPT
iptables -I OUTPUT 2 -o br0 -j ACCEPT
echo 1 > /sys/kernel/mm/ksm/run
Additionally, qemu-system-x86_64 version 2.1 doesn't have the same issue
running under OSX; it still works just fine with sudo. qemu-system-x86_64
version 1.1 (which shipped with KNOPPIX 7.0.3) also didn't have the same issue;
it worked just fine with sudo too.
-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.15.6-64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8.UTF-8, LC_CTYPE=en_US.UTF-8.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /UNIONFS/bin/bash
Versions of packages qemu depends on:
ii qemu-system 2.1+dfsg-7+b1
ii qemu-user 2.1+dfsg-7+b1
ii qemu-utils 2.1+dfsg-7+b1
qemu recommends no packages.
Versions of packages qemu suggests:
pn qemu-user-static <none>
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
