[Qemu-devel] [Bug 1185395] [NEW] qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

With a running VM I encounter this strange behaviour, former qemu-versions 
don't show up such an error.
Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with 
ceph-0.56.6?

( -95 might be a general Operation not supported error? )

Up to 1.4.2 everything is OK with savevm, though.

Any help welcome,

Oliver.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend
https://bugs.launchpad.net/bugs/1185395
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 1100843] Re: Live Migration Causes Performance Issues

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu14.12

---
qemu-kvm (1.0+noroms-0ubuntu14.12) precise-proposed; urgency=low

  * migration-do-not-overwrite-zero-pages.patch,
call-madv-hugepage-for-guest-ram-allocations.patch:
Fix performance degradation after migrations, and savevm/loadvm.
(LP: #1100843)
 -- Chris J Arges chris.j.ar...@ubuntu.com   Wed, 02 Oct 2013 16:26:27 -0500

** Changed in: qemu-kvm (Ubuntu Precise)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1100843

Title:
  Live Migration Causes Performance Issues

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Precise:
  Fix Released
Status in “qemu-kvm” source package in Quantal:
  Triaged
Status in “qemu-kvm” source package in Raring:
  Triaged
Status in “qemu-kvm” source package in Saucy:
  Fix Released

Bug description:
  SRU Justification
  [Impact]
   * Users of QEMU that save their memory states using savevm/loadvm or migrate 
experience worse performance after the migration/loadvm. To workaround these 
issues VMs must be completely rebooted. Optimally we should be able to restore 
a VM's memory state an expect no performance issue.

  [Test Case]

   * savevm/loadvm:
     - Create a VM and install a test suite such as lmbench.
     - Get numbers right after boot and record them.
     - Open up the qemu monitor and type the following:
   stop
   savevm 0
   loadvm 0
   c
     - Measure performance and record numbers.
     - Compare if numbers are within margin of error.
   * migrate:
     - Create VM, install lmbench, get numbers.
     - Open up qemu monitor and type the following:
   stop
   migrate exec:dd of=~/save.vm
   quit
     - Start a new VM using qemu but add the following argument:
   -incoming exec:dd if=~/save.vm
     - Run performance test and compare.

   If performance measured is similar then we pass the test case.

  [Regression Potential]

   * The fix is a backport of two upstream patches:
  ad0b5321f1f797274603ebbe20108b0750baee94
  211ea74022f51164a7729030b28eec90b6c99a08

  One patch allows QEMU to use THP if its enabled.
  The other patch changes logic to not memset pages to zero when loading memory 
for the vm (on an incoming migration).

   * I've also run the qa-regression-testing test-qemu.py script and it
  passes all tests.

  [Additional Information]

  Kernels from 3.2 onwards are affected, and all have the config:
  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y. Therefore enabling THP is
  applicable.

  --

  I have 2 physical hosts running Ubuntu Precise.  With 1.0+noroms-
  0ubuntu14.7 and qemu-kvm 1.2.0+noroms-0ubuntu7 (source from quantal,
  built for Precise with pbuilder.) I attempted to build qemu-1.3.0 debs
  from source to test, but libvirt seems to have an issue with it that I
  haven't been able to track down yet.

   I'm seeing a performance degradation after live migration on Precise,
  but not Lucid.  These hosts are managed by libvirt (tested both
  0.9.8-2ubuntu17 and 1.0.0-0ubuntu4) in conjunction with OpenNebula.  I
  don't seem to have this problem with lucid guests (running a number of
  standard kernels, 3.2.5 mainline and backported linux-
  image-3.2.0-35-generic as well.)

  I first noticed this problem with phoronix doing compilation tests,
  and then tried lmbench where even simple calls experience performance
  degradation.

  I've attempted to post to the kvm mailing list, but so far the only
  suggestion was it may be related to transparent hugepages not being
  used after migration, but this didn't pan out.  Someone else has a
  similar problem here -
  http://thread.gmane.org/gmane.comp.emulators.kvm.devel/100592

  qemu command line example: /usr/bin/kvm -name one-2 -S -M pc-1.2 -cpu
  Westmere -enable-kvm -m 73728 -smp 16,sockets=2,cores=8,threads=1
  -uuid f89e31a4-4945-c12c-6544-149ba0746c2f -no-user-config -nodefaults
  -chardev
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-2.monitor,server,nowait
  -mon chardev=charmonitor,id=monitor,mode=control -rtc
  base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device
  piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
  file=/var/lib/one//datastores/0/2/disk.0,if=none,id=drive-virtio-
  disk0,format=raw,cache=none -device virtio-blk-
  pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-
  disk0,bootindex=1 -drive
  file=/var/lib/one//datastores/0/2/disk.1,if=none,id=drive-
  ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive
  =drive-ide0-0-0,id=ide0-0-0 -netdev
  tap,fd=23,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-
  pci,netdev=hostnet0,id=net0,mac=02:00:0a:64:02:fe,bus=pci.0,addr=0x3
  -vnc 0.0.0.0:2,password -vga cirrus -incoming tcp:0.0.0.0:49155
  -device 

[Qemu-devel] [Bug 1243287] [NEW] [KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

On booting the cloud image using qemu/kvm fails with the following
error:

Cloud-init v. 0.7.3 running 'init' at Thu, 03 Oct 2013 16:45:21 +. Up 
360.78 seconds.
ci-info: +Net device info+
ci-info: ++--+---+---+---+
ci-info: | Device | Up | Address | Mask | Hw-Address |
ci-info: ++--+---+---+---+
ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . |
ci-info: | eth0 | True | 10.0.2.15 | 255.255.255.0 | 52:54:00:12:34:56 |
ci-info: ++--+---+---+---+
ci-info: ++Route info++
ci-info: +---+-+--+---+---+---+
ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
ci-info: +---+-+--+---+---+---+
ci-info: | 0 | 0.0.0.0 | 10.0.2.2 | 0.0.0.0 | eth0 | UG |
ci-info: | 1 | 10.0.2.0 | 0.0.0.0 | 255.255.255.0 | eth0 | U |
ci-info: +---+-+--+---+---+---+
error: kvm run failed Function not implemented

/usr/lib/python2.7/dist-packages/cloudinit/sources/DataSourceAltCloud.py
assumes that dmidecode command is availabe (ie it assumes that system is
x86) on arm systems there is no dmidecode command so host kvm fails with
the message error: kvm run failed Function not implemented

The patch makes get_cloud_type() function return with UNKNOWN for ARM
systems.

I was able to boot the cloud-image on ARM after applying this change.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
[KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
https://bugs.launchpad.net/bugs/1243287
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 1253563] [NEW] bad performance with rng-egd backend

[Launchpad Bug Tracker]

You have been subscribed to a public bug by Amos Kong (amoskong):


1. create listen socket
# cat /dev/random | nc -l localhost 1024

2. start vm with rng-egd backend

./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -mon 
chardev=qmp,mode=control,pretty=on -chardev 
socket,id=qmp,host=localhost,port=1234,server,nowait -m 2000 -device 
virtio-net-pci,netdev=h1,id=vnet0 -netdev tap,id=h1 -vnc :0 -drive 
file=/images/RHEL-64-virtio.qcow2 \
-chardev socket,host=localhost,port=1024,id=chr0 \
-object rng-egd,chardev=chr0,id=rng0 \
-device virtio-rng-pci,rng=rng0,max-bytes=1024000,period=1000

(guest) # dd if=/dev/hwrng of=/dev/null

note: cancelling dd process by Ctrl+c, it will return the read speed.

Problem:   the speed is around 1k/s

===

If I use rng-random backend (filename=/dev/random), the speed is about
350k/s).

It seems that when the request entry is added to the list, we don't read the 
data from queue list immediately.
The chr_read() is delayed, the virtio_notify() is delayed.  the next request 
will also be delayed. It effects the speed.

I tried to change rng_egd_chr_can_read() always returns 1,  the speed is
improved to (about 400k/s)

Problem: we can't poll the content in time currently


Any thoughts?

Thanks, Amos

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
bad performance with rng-egd backend
https://bugs.launchpad.net/bugs/1253563
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to the bug report.

[Qemu-devel] [Bug 1192499] [NEW] virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

virsh migration copy-storage-all  fails with Unable to read from
monitor: Connection reset by peer and shut downs the guest on the
source host.

Kernel Version:  3.10.0-rc5+

Libvirt Version: 1.0.6

Qemu Version: 1.5.50

Steps to reproduce the issue:

1. Created the qemu-img create -f qcow2 vm.qcow2 11G on the destination host 
which is same as the source.
2. Started the guest on the source
3. Started the vncdisplay to monitor the guest
4. Initiated the migration virsh migrate --live VM1 qemu+ssh://host-ip/system 
tcp://host-ip --verbose --copy-storage-all
5. It started the copying the storage from souce to destination (conitinously 
monitored it was growing)
6. Guest on the destination was paused and was running on the source
7. At some point the VM on the source got shutdown and migration failed with 
Unable to read from monitor: Connection reset by peer

Attached the libvirt debug logs.

The debug logs shows :

2013-06-19 08:43:12.253+: 4026: debug : virEventPollInterruptLocked:716 : 
Interrupting
2013-06-19 08:43:12.253+: 4026: debug : virEventPollAddTimeout:248 : 
EVENT_POLL_ADD_TIMEOUT: timer=1 frequency=0 cb=0x7fe930baa960 opaque=(nil) 
ff=(nil)

Note: The virsh live migration works fine with nfs storage from source to 
destination and vice versa.
With libvirt 1.0.5 and qemu 1.5 also we were facing the same issue, but with 
that even Live migration with nfs also was not working.

Guest XML:


domain type='kvm'
  nameVM1/name
  uuid47feb0e1-0c23-9be9-da12-2ead34864de2/uuid
  memory unit='KiB'4096000/memory
  currentMemory unit='KiB'2048000/currentMemory
  vcpu placement='auto'1/vcpu
  numatune
memory mode='strict' nodeset='0'/
  /numatune
  os
type arch='x86_64' machine='pc-i440fx-1.5'hvm/type
boot dev='hd'/
  /os
  features
acpi/
apic/
pae/
  /features
  clock offset='utc'/
  on_poweroffdestroy/on_poweroff
  on_rebootrestart/on_reboot
  on_crashrestart/on_crash
  devices
emulator/usr/local/bin/qemu-system-x86_64/emulator
disk type='file' device='disk'
  driver name='qemu' type='qcow2' cache='none'/
  source file='/home/images/VM1.qcow2'/
  target dev='hda' bus='ide'/
  address type='drive' controller='0' bus='0' target='0' unit='0'/
/disk
disk type='block' device='cdrom'
  driver name='qemu' type='raw'/
  target dev='hdc' bus='ide'/
  readonly/
  address type='drive' controller='0' bus='1' target='0' unit='0'/
/disk
controller type='usb' index='0'
  address type='pci' domain='0x' bus='0x00' slot='0x01' 
function='0x2'/
/controller
controller type='ide' index='0'
  address type='pci' domain='0x' bus='0x00' slot='0x01' 
function='0x1'/
/controller
controller type='pci' index='0' model='pci-root'/
interface type='network'
  mac address='52:54:00:9d:cf:bb'/
  source network='default'/
  model type='rtl8139'/
  address type='pci' domain='0x' bus='0x00' slot='0x03' 
function='0x0'/
/interface
serial type='pty'
  target port='0'/
/serial
console type='pty'
  target type='serial' port='0'/
/console
input type='mouse' bus='ps2'/
graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'
  listen type='address' address='127.0.0.1'/
/graphics
video
  model type='cirrus' vram='9216' heads='1'/
  address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
/video
memballoon model='virtio'
  address type='pci' domain='0x' bus='0x00' slot='0x05' 
function='0x0'/
/memballoon
  /devices
  seclabel type='none' model='selinux'/
/domain

** Affects: qemu
 Importance: Undecided
 Status: New

** Affects: libvirt (Ubuntu)
 Importance: Medium
 Status: Invalid

-- 
virsh migration copy-storage-all  fails with Unable to read from monitor: 
Connection reset by peer
https://bugs.launchpad.net/bugs/1192499
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice

[Launchpad Bug Tracker]

** Branch linked: lp:~bdrung/qemu-kvm/caps-lock-key-up-event

-- 
kvm sends caps lock key up event twice
https://bugs.launchpad.net/bugs/427612
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: In Progress
Status in “libsdl1.2” source package in Maverick: Invalid
Status in “qemu-kvm” source package in Maverick: New
Status in “libsdl1.2” package in Debian: Fix Released

Bug description:
Binary package hint: qemu-kvm

I have set the keyboard layout to German NEO 2 [1] in the host and the client 
(both current karmic). The caps lock is used as modifier (similar to shift) in 
NEO. When I press caps lock + t, then the client prints a t instead of a 
-. A caps lock key up event is sent to the client before I release the caps 
lock key.

[1] http://www.neo-layout.org/

ProblemType: Bug
Architecture: amd64
Date: Fri Sep 11 01:38:58 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
Package: qemu-kvm 0.11.0~rc2-0ubuntu2
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic 
root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-10-generic x86_64
dmi.bios.date: 07/15/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-802
dmi.chassis.type: 3
dmi.modalias: 
dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:

[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice

[Launchpad Bug Tracker]

** Branch linked: lp:~bdrung/qemu-kvm/caps-lock-key-up-event.maverick

-- 
kvm sends caps lock key up event twice
https://bugs.launchpad.net/bugs/427612
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: In Progress
Status in “libsdl1.2” source package in Maverick: Invalid
Status in “qemu-kvm” source package in Maverick: New
Status in “libsdl1.2” package in Debian: Fix Released

Bug description:
Binary package hint: qemu-kvm

I have set the keyboard layout to German NEO 2 [1] in the host and the client 
(both current karmic). The caps lock is used as modifier (similar to shift) in 
NEO. When I press caps lock + t, then the client prints a t instead of a 
-. A caps lock key up event is sent to the client before I release the caps 
lock key.

[1] http://www.neo-layout.org/

ProblemType: Bug
Architecture: amd64
Date: Fri Sep 11 01:38:58 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
Package: qemu-kvm 0.11.0~rc2-0ubuntu2
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic 
root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-10-generic x86_64
dmi.bios.date: 07/15/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-802
dmi.chassis.type: 3
dmi.modalias: 
dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:

[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.13.0+noroms-0ubuntu8

---
qemu-kvm (0.13.0+noroms-0ubuntu8) natty; urgency=low

  * Add caps-lock-key-up-event.patch to enable normal up/down events for
Caps-Lock and Num-Lock keys by setting SDL_DISABLE_LOCK_KEYS (which
requires SDL  1.2.14). This fixes handling of capslock when capslock is
mapped to something else in host system. (LP: #427612)
 -- Benjamin Drung bdr...@ubuntu.com   Wed, 24 Nov 2010 21:46:44 +0100

** Changed in: qemu-kvm (Ubuntu)
   Status: In Progress = Fix Released

-- 
kvm sends caps lock key up event twice
https://bugs.launchpad.net/bugs/427612
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “libsdl1.2” source package in Maverick: Invalid
Status in “qemu-kvm” source package in Maverick: Fix Committed
Status in “libsdl1.2” package in Debian: Fix Released

Bug description:
Binary package hint: qemu-kvm

I have set the keyboard layout to German NEO 2 [1] in the host and the client 
(both current karmic). The caps lock is used as modifier (similar to shift) in 
NEO. When I press caps lock + t, then the client prints a t instead of a 
-. A caps lock key up event is sent to the client before I release the caps 
lock key.

[1] http://www.neo-layout.org/

ProblemType: Bug
Architecture: amd64
Date: Fri Sep 11 01:38:58 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
Package: qemu-kvm 0.11.0~rc2-0ubuntu2
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic 
root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-10-generic x86_64
dmi.bios.date: 07/15/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-802
dmi.chassis.type: 3
dmi.modalias: 
dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:

[Qemu-devel] [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu9.3

---
qemu-kvm (0.12.3+noroms-0ubuntu9.3) lucid-proposed; urgency=low

  * Fix segfault when using scsi with writeback (LP: #595438)
 -- Serge Hallyn serge.hal...@canonical.com   Wed, 28 Jul 2010 09:56:56 -0500

** Changed in: qemu-kvm (Ubuntu Lucid)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/595438

Title:
  KVM segmentation fault, using SCSI+writeback and linux 2.4 guest

Status in Kernel Virtual Machine:
  Confirmed
Status in QEMU:
  Fix Committed
Status in qemu-kvm:
  Fix Released
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “qemu-kvm” package in Debian:
  Fix Released

Bug description:
  I Use Ubuntu 32 bit 10.04 with standard KVM.
I have Intel E7600  @ 3.06GHz processor with VMX

In this system I Run:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name 
spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait 
-monitor chardev:monitor -boot d -drive 
file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive 
file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback 
-net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 
-chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 
127.0.0.1:0 -vga cirrus

.iso image contain custom distro of 2.4-linux kernel based system. During 
install process (when .tar.gz actively unpacked), kvm dead with segmentation 
fault.

And ONLY when I choose scsi virtual disk and writeback simultaneously.
But, writeback+ide, writethrough+scsi works OK.

I use qcow2. It seems, that qcow does not have such problems.

Virtual machine get down at random time during file copy. It seems, when qcow2 
file size need to be expanded.

IMPACT: kvm used with scsi virtual disk and writeback dies with segfault.

FIX: is the inclusion of a patch cherry-picked from upstream which dequeues
requests before invoking callbacks.  It is at
http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70

TO REPRODUCE: See the command above.

REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been
tested by the bug reporter with no ill effects.

[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.12.5+noroms-0ubuntu7.1

---
qemu-kvm (0.12.5+noroms-0ubuntu7.1) maverick-proposed; urgency=low

  * Add caps-lock-key-up-event.patch to enable normal up/down events for
Caps-Lock and Num-Lock keys by setting SDL_DISABLE_LOCK_KEYS (which
requires SDL  1.2.14). This fixes handling of capslock when capslock is
mapped to something else in host system. (LP: #427612)
 -- Benjamin Drung bdr...@ubuntu.com   Wed, 24 Nov 2010 15:35:10 +0100

** Changed in: qemu-kvm (Ubuntu Maverick)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/427612

Title:
  kvm sends caps lock key up event twice

Status in QEMU:
  New
Status in “libsdl1.2” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libsdl1.2” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  Fix Released
Status in “libsdl1.2” package in Debian:
  Fix Released

Bug description:
  Binary package hint: qemu-kvm

I have set the keyboard layout to German NEO 2 [1] in the host and the client 
(both current karmic). The caps lock is used as modifier (similar to shift) in 
NEO. When I press caps lock + t, then the client prints a t instead of a 
-. A caps lock key up event is sent to the client before I release the caps 
lock key.

[1] http://www.neo-layout.org/

ProblemType: Bug
Architecture: amd64
Date: Fri Sep 11 01:38:58 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
Package: qemu-kvm 0.11.0~rc2-0ubuntu2
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic 
root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-10-generic x86_64
dmi.bios.date: 07/15/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-802
dmi.chassis.type: 3
dmi.modalias: 
dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:

TEST CASE: Select NEO2 as keyboard layout in your guest system and press 'caps 
lock' + 't'. A '-' should appear.

[Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing writeback cache option

[Launchpad Bug Tracker]

[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu-kvm (Ubuntu)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/595117

Title:
  qemu-nbd slow and missing writeback cache option

Status in QEMU:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Expired

Bug description:
  Binary package hint: qemu-kvm

dpkg -l | grep qemu
ii  kvm  
1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9dummy transitional 
pacakge from kvm to qemu-
ii  qemu 0.12.3+noroms-0ubuntu9 
   dummy transitional pacakge from qemu to qemu
ii  qemu-common  0.12.3+noroms-0ubuntu9 
   qemu common functionality (bios, documentati
ii  qemu-kvm 0.12.3+noroms-0ubuntu9 
   Full virtualization on i386 and amd64 hardwa
ii  qemu-kvm-extras  0.12.3+noroms-0ubuntu9 
   fast processor emulator binaries for non-x86
ii  qemu-launcher1.7.4-1ubuntu2 
   GTK+ front-end to QEMU computer emulator
ii  qemuctl  0.2-2  
   controlling GUI for qemu

lucid amd64.

qemu-nbd is a lot slower when writing to disk than say nbd-server.

It appears it is because by default the disk image it serves is open with 
O_SYNC. The --nocache option, unintuitively, makes matters a bit better because 
it causes the image to be open with O_DIRECT instead of O_SYNC.

The qemu code allows an image to be open without any of those flags, but 
unfortunately qemu-nbd doesn't have the option to do that (qemu doesn't allow 
the image to be open with both O_SYNC and O_DIRECT though).

The default of qemu-img (of using O_SYNC) is not very sensible because anyway, 
the client (the kernel) uses caches (write-back), (and qemu-nbd -d doesn't 
flush those by the way). So if for instance qemu-nbd is killed, regardless of 
whether qemu-nbd uses O_SYNC, O_DIRECT or not, the data in the image will not 
be consistent anyway, unless syncs are done by the client (like fsync on the 
nbd device or sync mount option), and with qemu-nbd's O_SYNC mode, those 
syncs will be extremely slow.

Attached is a patch that adds a --cache={off,none,writethrough,writeback} 
option to qemu-nbd.

--cache=off is the same as --nocache (that is use O_DIRECT), writethrough is 
using O_SYNC and is still the default so this patch doesn't change the 
functionality. writeback is none of those flags, so is the addition of this 
patch. The patch also does an fsync upon qemu-nbd -d to make sure data is 
flushed to the image before removing the nbd.

Consider this test scenario:

dd bs=1M count=100 of=a  /dev/null
qemu-nbd --cache=x -c /dev/nbd0 a
cp /dev/zero /dev/nbd0
time perl -MIO::Handle -e 'STDOUT-sync or die$!' 1 /dev/nbd0

With cache=writethrough (the default), it takes over 10 minutes to write those 
100MB worth of zeroes. Running a strace, we see the recvfrom and sentos delayed 
by each 1kb write(2)s to disk (10 to 30 ms per write).

With cache=off, it takes about 30 seconds.

With cache=writeback, it takes about 3 seconds, which is similar to the 
performance you get with nbd-server

Note that the cp command runs instantly as the data is buffered by the client 
(the kernel), and not sent to qemu-nbd until the fsync(2) is called.

[Qemu-devel] [Bug 543478] Re: qemus pmemsave doesn't accept / in filename

[Launchpad Bug Tracker]

[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu-kvm (Ubuntu)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/543478

Title:
  qemus pmemsave doesn't accept / in filename

Status in QEMU:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Expired

Bug description:
  Binary package hint: qemu-kvm

Please see my conversation with qemu:

(qemu) pmemsave 
unexpected end of expression
(qemu) help pmemsave 
pmemsave addr size file -- save to disk physical memory dump starting at 'addr' 
of size 'size'
(qemu) pmemsave 0 512M /tmp/qemu.mem
pmemsave: extraneous characters at the end of line
(qemu) pmemsave 0 512 /tmp/qemu.mem
invalid char in expression
(qemu) pmemsave 0 512 /tmp/qemu
invalid char in expression
(qemu) pmemsave 0 512 qemu.mem
(qemu) pmemsave 0 512M qemu.mem
pmemsave: extraneous characters at the end of line



Let me comment on each one of those:
(qemu) pmemsave 
unexpected end of expression

I expected some sort of hint as to where to get more information. Maybe just a 
Type ``help pmemsave'' to get syntax information would be sufficient.


(qemu) help pmemsave 
pmemsave addr size file -- save to disk physical memory dump starting at 'addr' 
of size 'size'

Nice. But an example would be nice. My proposal: I.e.: pmemsave 0 1G 
/tmp/qemu.mem


(qemu) pmemsave 0 512M /tmp/qemu.mem
pmemsave: extraneous characters at the end of line

eh. Would be nice if it told me *which* character was extraneous and what 
extraneous means. My proposal: Couldn't parse character at position 23, 
please see help pmemsave for an example.


(qemu) pmemsave 0 512 /tmp/qemu.mem
invalid char in expression

Hm. Interesting. Again, would be nice if it printed me the offending character. 
My proposal: Could not parse character at position 23, please see help 
pmemsave for an example.


(qemu) pmemsave 0 512 /tmp/qemu
invalid char in expression

Now I got rid of almost everything but it still doesn't work.


(qemu) pmemsave 0 512 qemu.mem

aha! No slashes?! Seriously?

(qemu) pmemsave 0 512M qemu.mem
pmemsave: extraneous characters at the end of line

And no M or G modifiers? If I want to dump 2GB then I'd have to calculate 
the number in bytes and paste that long string. I expected qemu to be able to 
parse the K, M, G suffixes.

Also, I'm wondering why it doesn't offer to dump all memory.

ProblemType: Bug
Architecture: amd64
CurrentDmesg:
 [150870.676062] kvm_intel: Unknown symbol kvm_vcpu_on_spin
 [150947.222923] cron[24260]: segfault at 0 ip (null) sp 7fffe865eed8 error 
14 in cron[40+9000]
 [150947.224187] cron[24261]: segfault at 0 ip (null) sp 7fffe865eed8 error 
14 in cron[40+9000]
Date: Sun Mar 21 15:03:13 2010
DistroRelease: Ubuntu 9.10
KvmCmdLine:
 UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
 muelli   23807 23806 13 239738 228464 0 14:54 pts/800:01:22 /usr/bin/kvm 
-S -M pc -m 512 -smp 1 -name vanilla_ubuntu -monitor stdio -boot c -drive 
file=/home/muelli/qemu/ubuntu8.10/ubuntu.img,if=ide,index=0,boot=on -drive 
file=,if=ide,media=cdrom,index=2 -net 
nic,model=rtl8139,macaddr=f0:00:BA:12:34:56 -net 
user,hostfwd=tcp::2223-:22,smb=/tmp/share -serial pty -snapshot
MachineType: LENOVO 766636G
Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=/dev/mapper/cryptroot 
source=UUID=9c3d5596-27c6-4fd5-bfcd-fa8eef6f1230 ro vdso32=0 quiet splash  
crashkernel=384M-2G:64M,2G-:128M
ProcVersionSignature: Ubuntu 2.6.32-16.24-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.32-16-generic x86_64
dmi.bios.date: 03/12/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 7NETC0WW (2.20 )
dmi.board.name: 766636G
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: 
dmi:bvnLENOVO:bvr7NETC0WW(2.20):bd03/12/2009:svnLENOVO:pn766636G:pvrThinkPadX61:rvnLENOVO:rn766636G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 766636G
dmi.product.version: ThinkPad X61
dmi.sys.vendor: LENOVO

[Qemu-devel] [Bug 563582] Re: KVM 9.10 crashes for suse-10 as guest

[Launchpad Bug Tracker]

[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu-kvm (Ubuntu)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/563582

Title:
  KVM 9.10 crashes for suse-10 as guest

Status in QEMU:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Expired

Bug description:
  Binary package hint: qemu-kvm

  I have tried KVM of Ubuntu 9.10 Karmic,Koala,Version for virtualization; on 
64 bit hardware platform
  I have installed, 4 VM's (Win2k3, TWO WIN-XP's , One Suse-10 Enterprise 
Edition);
  I observe that suse-10 virtual machine, crashes after about 2-5 hours;
  Now after I have installed oracle,in suse-10 PC seems to crash
  (KVM crash after 1 hour; Anyway to see the logs after the crash.
  How to analyse such abnormal activities;Pls guide me
  I read your post on changing the network card interface to e1000,r8139 it 
does not work for me;
  Can you please suggest, how to resolve this issue since it is very urgent
  and important;
  Many thanks
  Raghav

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

** Branch linked: lp:~brightbox/ubuntu/maverick/qemu-kvm/qemu-
kvm.fix-697197

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  New
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Confirmed

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.13.0+noroms-0ubuntu13

---
qemu-kvm (0.13.0+noroms-0ubuntu13) natty; urgency=low

  [ Neil Wilson n...@aldur.co.uk ]
  * SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197)
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
  change introduced in Qemu by git commit 52c18be9
- CVE: 2011-0011

  [ Dustin Kirkland ]
  * Updated patch to reflect the move of vnc.c to ui/vnc.c
 -- Dustin Kirkland kirkl...@ubuntu.com   Fri, 11 Feb 2011 09:53:19 -0600

** Changed in: qemu-kvm (Ubuntu Natty)
   Status: In Progress = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  New
Status in “qemu-kvm” source package in Lucid:
  In Progress
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  In Progress
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

** Branch linked: lp:~kirkland/ubuntu/natty/qemu-kvm/fix-build

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  New
Status in “qemu-kvm” source package in Lucid:
  In Progress
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  In Progress
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/qemu-kvm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  New
Status in “qemu-kvm” source package in Lucid:
  In Progress
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  In Progress
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.12.5+noroms-0ubuntu7.2

---
qemu-kvm (0.12.5+noroms-0ubuntu7.2) maverick-security; urgency=low

  [ Dustin Kirkland ]
  * SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197).
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
  change introduced in Qemu by git commit 52c18be9, thanks to Neil Wilson.
- CVE-2011-0011

  [ Kees Cook ]
  * debian/rules: disable parallel build; fix FTBFS.
 -- Kees Cook k...@ubuntu.com   Fri, 11 Feb 2011 15:52:12 -0800

** Changed in: qemu-kvm (Ubuntu Maverick)
   Status: Fix Committed = Fix Released

** Changed in: qemu-kvm (Ubuntu Lucid)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Invalid
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  Fix Released
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released
Status in “libvirt” source package in Karmic:
  Invalid
Status in “qemu-kvm” source package in Karmic:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.11.0-0ubuntu6.4

---
qemu-kvm (0.11.0-0ubuntu6.4) karmic-security; urgency=low

  * SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197)
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
  change introduced in Qemu by git commit 52c18be9, thanks to Neil Wilson.
- CVE-2011-0011
 -- Dustin Kirkland kirkl...@ubuntu.com   Fri, 11 Feb 2011 17:46:26 -0600

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Invalid
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  Fix Released
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released
Status in “libvirt” source package in Karmic:
  Invalid
Status in “qemu-kvm” source package in Karmic:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu9.4

---
qemu-kvm (0.12.3+noroms-0ubuntu9.4) lucid-security; urgency=low

  * SECURITY UPDATE: Setting VNC password to empty string silently
disables all authentication (LP: #697197)
- debian/patches/697197-fix-vnc-password-semantics.patch: Reverses the
  change introduced in Qemu by git commit 52c18be9, thanks to Neil Wilson.
- CVE-2011-0011
 -- Dustin Kirkland kirkl...@ubuntu.com   Fri, 11 Feb 2011 09:57:30 -0600

** Changed in: qemu-kvm (Ubuntu Karmic)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Invalid
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  Fix Released
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released
Status in “libvirt” source package in Karmic:
  Invalid
Status in “qemu-kvm” source package in Karmic:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 595438] Re: KVM segmentation fault, using SCSI+writeback and linux 2.4 guest

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/lucid-proposed/qemu-kvm

-- 
KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
https://bugs.launchpad.net/bugs/595438
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in Kernel Virtual Machine: Confirmed
Status in QEMU: Fix Committed
Status in qemu-kvm: Fix Released
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “qemu-kvm” source package in Lucid: Fix Committed

Bug description:
I Use Ubuntu 32 bit 10.04 with standard KVM.
I have Intel E7600  @ 3.06GHz processor with VMX

In this system I Run:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -name 
spamsender -uuid b9cacd5e-08f7-41fd-78c8-89cec59af881 -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/spamsender.monitor,server,nowait 
-monitor chardev:monitor -boot d -drive 
file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive 
file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback 
-net nic,macaddr=00:00:00:00:00:00,vlan=0,name=nic.0 -net tap,vlan=0,name=tap.0 
-chardev pty,id=serial0 -serial chardev:serial0 -parallel none -usb -vnc 
127.0.0.1:0 -vga cirrus

.iso image contain custom distro of 2.4-linux kernel based system. During 
install process (when .tar.gz actively unpacked), kvm dead with segmentation 
fault.

And ONLY when I choose scsi virtual disk and writeback simultaneously.
But, writeback+ide, writethrough+scsi works OK.

I use qcow2. It seems, that qcow does not have such problems.

Virtual machine get down at random time during file copy. It seems, when qcow2 
file size need to be expanded.

IMPACT: kvm used with scsi virtual disk and writeback dies with segfault.

FIX: is the inclusion of a patch cherry-picked from upstream which dequeues
requests before invoking callbacks.  It is at
http://bazaar.launchpad.net/~serge-hallyn/ubuntu/lucid/qemu-kvm/fix-scsi-writeback/revision/70

TO REPRODUCE: See the command above.

REGRESSION POTENTIAL: this is cherry-picked from upstream, and has been
tested by the bug reporter with no ill effects.

[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.12.5+noroms-0ubuntu6

---
qemu-kvm (0.12.5+noroms-0ubuntu6) maverick; urgency=low

  * debian/fix-CMOS-info-for-drives-defined-with--device.patch: make sure
the CMOS knows about the correct geometry so Windows XP installs
properly. (LP: #586175)
 -- Marc Deslauriers marc.deslauri...@ubuntu.com   Wed, 15 Sep 2010 19:48:15 
-0400

** Changed in: qemu-kvm (Ubuntu)
   Status: New = Fix Released

-- 
Windows XP/2003 doesn't boot
https://bugs.launchpad.net/bugs/586175
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in Debian GNU/Linux: Fix Released
Status in Fedora: Unknown

Bug description:
Hello everyone,

my qemu doesn't boot any Windows XP/2003 installations if I try to boot the 
image.
If I boot the install cd first, it's boot manager counts down and triggers the 
boot on it's own. That's kinda stupid.

I'm using libvirt, but even by a simple
 qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on
it won't boot. Qemu hangs at the message Booting from Hard Disk...

I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). 
It's a server, that means I'm using VNC as the primary graphic output but i 
don't think it should be an issue.

[Qemu-devel] [Bug 586175] Re: Windows XP/2003 doesn't boot

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/qemu-kvm

-- 
Windows XP/2003 doesn't boot
https://bugs.launchpad.net/bugs/586175
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in Debian GNU/Linux: Fix Released
Status in Fedora: Unknown

Bug description:
Hello everyone,

my qemu doesn't boot any Windows XP/2003 installations if I try to boot the 
image.
If I boot the install cd first, it's boot manager counts down and triggers the 
boot on it's own. That's kinda stupid.

I'm using libvirt, but even by a simple
 qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on
it won't boot. Qemu hangs at the message Booting from Hard Disk...

I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). 
It's a server, that means I'm using VNC as the primary graphic output but i 
don't think it should be an issue.

[Qemu-devel] [Bug 453617] Re: kvm hangs at 100% cpu when connecting to forwarded ports (when listed incorrectly on the command line)

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/qemu-kvm

-- 
kvm hangs at 100% cpu when connecting to forwarded ports (when listed 
incorrectly on the command line)
https://bugs.launchpad.net/bugs/453617
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Confirmed
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “qemu-kvm” source package in Lucid: Fix Released

Bug description:
Binary package hint: qemu-kvm

If kvm is started using two separate -net user,hostfwd=forwarding rule 
arguments to forward ports from the host to the client, it won't complain, but 
will return a connection refused error and hang at 100% cpu when trying to 
connect to either forwarded port.

However, if kvm is started with the hostfwd rules combined together into a 
single -net user argument, it works fine.

As an example, this command line doesn't generate any warnings or errors, but 
causes kvm to hang for me:

kvm -net nic -net user,hostfwd=tcp:127.0.0.1:-:80 -net 
user,hostfwd=tcp:127.0.0.1:-:22 -m 128 -smp 1 -drive file=disk0.qcow2

... but this command line works fine:

kvm -net nic -net 
user,hostfwd=tcp:127.0.0.1:-:80,hostfwd=tcp:127.0.0.1:-:22 -m 128 -smp 
1 -drive file=disk0.qcow2

ProblemType: Bug
Architecture: amd64
Date: Fri Oct 16 17:19:59 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
MachineType: Sony Corporation VGN-SZ650N
NonfreeKernelModules: nvidia
Package: kvm (not installed)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=UUID=3ee4953e-48f0-497c-ae78-18cbb18cfef8 ro quiet splash
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.47-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-14-generic x86_64
dmi.bios.date: 07/12/2007
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: R0081S5
dmi.board.asset.tag: N/A
dmi.board.name: VAIO
dmi.board.vendor: Sony Corporation
dmi.board.version: N/A
dmi.chassis.type: 10
dmi.chassis.vendor: Sony Corporation
dmi.chassis.version: N/A
dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvrR0081S5:bd07/12/2007:svnSonyCorporation:pnVGN-SZ650N:pvrJ002VXGP:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:
dmi.product.name: VGN-SZ650N
dmi.product.version: J002VXGP
dmi.sys.vendor: Sony Corporation

[Qemu-devel] [Bug 427612] Re: does not pass pressed caps lock to client

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/qemu-kvm

-- 
does not pass pressed caps lock to client
https://bugs.launchpad.net/bugs/427612
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New
Status in “libsdl1.2” package in Ubuntu: Invalid
Status in “qemu-kvm” package in Ubuntu: Fix Released
Status in “libsdl1.2” package in Debian: Fix Released

Bug description:
Binary package hint: qemu-kvm

I have set the keyboard layout to German NEO 2 [1] in the host and the client 
(both current karmic). The caps lock is used as modifier (similar to shift) in 
NEO. When I press caps lock + t, then the client prints a t instead of a 
-. It seems that the pressed caps lock is not passed to the client.

[1] http://www.neo-layout.org/

ProblemType: Bug
Architecture: amd64
Date: Fri Sep 11 01:38:58 2009
DistroRelease: Ubuntu 9.10
KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
Package: qemu-kvm 0.11.0~rc2-0ubuntu2
PccardctlIdent:
 
PccardctlStatus:
 
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic 
root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.31-generic
SourcePackage: qemu-kvm
Uname: Linux 2.6.31-10-generic x86_64
dmi.bios.date: 07/15/2009
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-802
dmi.chassis.type: 3
dmi.modalias: 
dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr:

[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl

[Launchpad Bug Tracker]

** Branch linked: lp:~serge-hallyn/ubuntu/natty/qemu-kvm/qxl-lock

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/723871

Title:
  qemu-kvm-0.14.0 Aborts with -vga qxl

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  New

Bug description:
  Host CPU is Core i7 Q820.  KVM is from 2.6.35-gentoo-r5 kernel (x86_64).
  Host has spice-0.7.2 and spice-protocol-0.7.0.
  Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and 
vdagent 0.6.3.

  qemu-kvm is started like so:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive 
file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 
768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl 
-device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -monitor stdio
  and crashes with:
  qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: 
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
  Aborted

  If I use -no-kvm, it works fine.  If I use -vga std, it works fine.
  -enable-kvm and -vga qxl crashes.

[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.14.0~rc1+noroms-0ubuntu4

---
qemu-kvm (0.14.0~rc1+noroms-0ubuntu4) natty; urgency=low

  * Apply spice-qxl-locking-fix-for-qemu-kvm.patch to fix bug with -qxl.
(LP: #723871)
 -- Serge Hallyn serge.hal...@ubuntu.com   Tue, 01 Mar 2011 11:12:44 -0600

** Changed in: qemu-kvm (Ubuntu)
   Status: In Progress = Fix Released

** Branch linked: lp:ubuntu/qemu-kvm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/723871

Title:
  qemu-kvm-0.14.0 Aborts with -vga qxl

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Host CPU is Core i7 Q820.  KVM is from 2.6.35-gentoo-r5 kernel (x86_64).
  Host has spice-0.7.2 and spice-protocol-0.7.0.
  Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and 
vdagent 0.6.3.

  qemu-kvm is started like so:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive 
file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 
768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl 
-device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -monitor stdio
  and crashes with:
  qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: 
kvm_mutex_unlock: Assertion `!cpu_single_env' failed.
  Aborted

  If I use -no-kvm, it works fine.  If I use -vga std, it works fine.
  -enable-kvm and -vga qxl crashes.

[Qemu-devel] [Bug 584143] Re: qemu fails to set hdd serial number

[Launchpad Bug Tracker]

** Branch linked: lp:~serge-hallyn/ubuntu/lucid/qemu-kvm/hdd-serial

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/584143

Title:
  qemu fails to set hdd serial number

Status in QEMU:
  Fix Released
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Lucid:
  Confirmed
Status in “qemu-kvm” source package in Maverick:
  New
Status in “qemu-kvm” package in Debian:
  Unknown

Bug description:
  The -drive ...,serial=xyz option is broken, at least in 0.12.  See
  Debian bug#573439, http://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=573439 for details.

  The proposed fix from the original reporter:

  --- qemu-kvm-0.12.3+dfsg/vl.c 2010-02-26 11:34:00.0 +0900
  +++ qemu-kvm-0.12.3+dfsg.old/vl.c 2010-03-11 02:26:00.134217787 +0900
  @@ -2397,7 +2397,7 @@
   dinfo-on_write_error = on_write_error;
   dinfo-opts = opts;
   if (serial)
  -strncpy(dinfo-serial, serial, sizeof(serial));
  +strncpy(dinfo-serial, serial, sizeof(dinfo-serial));
   QTAILQ_INSERT_TAIL(drives, dinfo, next);
   if (is_extboot) {
   extboot_drive = dinfo;

[Qemu-devel] [Bug 584143] Re: qemu fails to set hdd serial number

[Launchpad Bug Tracker]

** Branch linked: lp:~serge-hallyn/ubuntu/maverick/qemu-kvm/hdd-serial

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/584143

Title:
  qemu fails to set hdd serial number

Status in QEMU:
  Fix Released
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Lucid:
  Confirmed
Status in “qemu-kvm” source package in Maverick:
  New
Status in “qemu-kvm” package in Debian:
  Unknown

Bug description:
  The -drive ...,serial=xyz option is broken, at least in 0.12.  See
  Debian bug#573439, http://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=573439 for details.

  The proposed fix from the original reporter:

  --- qemu-kvm-0.12.3+dfsg/vl.c 2010-02-26 11:34:00.0 +0900
  +++ qemu-kvm-0.12.3+dfsg.old/vl.c 2010-03-11 02:26:00.134217787 +0900
  @@ -2397,7 +2397,7 @@
   dinfo-on_write_error = on_write_error;
   dinfo-opts = opts;
   if (serial)
  -strncpy(dinfo-serial, serial, sizeof(serial));
  +strncpy(dinfo-serial, serial, sizeof(dinfo-serial));
   QTAILQ_INSERT_TAIL(drives, dinfo, next);
   if (is_extboot) {
   extboot_drive = dinfo;

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/maverick-updates/qemu-kvm

** Branch linked: lp:ubuntu/lucid-updates/qemu-kvm

** Branch linked: lp:ubuntu/karmic-security/qemu-kvm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Invalid
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  Fix Released
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released
Status in “libvirt” source package in Karmic:
  Invalid
Status in “qemu-kvm” source package in Karmic:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 814222] Re: kvm cannot use vhd files over 127GB

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/qemu-kvm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/814222

Title:
  kvm cannot use vhd files over 127GB

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  The primary use case for using vhds with KVM is to perform a
  conversion to a raw image file so that one could move from Hyper-V to
  Linux-KVM.  See more on this http://blog.allanglesit.com/2011/03
  /linux-kvm-migrating-hyper-v-vhd-images-to-kvm/

  # kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img

  The above works great if you have VHDs smaller than 127GB, however if
  it is larger, then no error is generated during the conversion
  process, but it appears to just process up to that 127GB barrier and
  no more.  Also of note.  VHDs can also be run directly using KVM if
  they are smaller than 127GB.  VHDs can be read and function well using
  virtualbox as well as hyper-v, so I suspect the problem lies not with
  the VHD format (since that has a 2TB limitation).  But instead with
  how qemu-kvm is interpreting them.

  BORING VERSION INFO:
  # cat /etc/issue
  Ubuntu 11.04 \n \l
  # uname -rmiv
  2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64
  # apt-cache policy kvm
  kvm:
Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1
Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1
Version table:
   *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0
  500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages
  500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages
  100 /var/lib/dpkg/status
   1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0
  500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages
  # apt-cache policy libvirt-bin
  libvirt-bin:
Installed: 0.8.8-1ubuntu6.2
Candidate: 0.8.8-1ubuntu6.2
Version table:
   *** 0.8.8-1ubuntu6.2 0
  500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages
  500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages
  100 /var/lib/dpkg/status
   0.8.8-1ubuntu6 0
  500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages

  qemu-img version 0.14.0

  # vboxmanage -v
  4.0.12r72916

  
  REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with  1GB of free 
space)

  ##  WINDOWS  MACHINE  ##

  Use Computer Management  Disk Management
  -Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively.
  -Do not initialize  or format.

  These files will need to be transferred to an Ubuntu KVM machine (pscp
  is what I used but usb would work as well).

  ##  UBUNTU KVM MACHINE  ##

  # ls *.vhd
  120g-dyn.vhd  140g-dyn.vhd
  # kvm-img info 120g-dyn.vhd 
  image: 120g-dyn.vhd
  file format: vpc
  virtual size: 120G (128847052800 bytes)
  disk size: 244K
  # kvm-img info 140g-dyn.vhd 
  image: 140g-dyn.vhd
  file format: vpc
  virtual size: 127G (13683600 bytes)
  disk size: 284K
  # kvm-img info 120g-dyn.vhd | grep virtual size
  virtual size: 120G (128847052800 bytes)
  # kvm-img info 140g-dyn.vhd | grep virtual size
  virtual size: 127G (13683600 bytes)

  Regardless of how big the second vhd is I always get a virtual size of
  127G

  Now if we use virtualbox to view the vhds we see markedly different
  results.

  # VBoxManage showhdinfo 120g-dyn.vhd
  UUID: e63681e0-ff12-4114-85de-7d13562b36db
  Accessible:   yes
  Logical size: 122880 MBytes
  Current size on disk: 0 MBytes
  Type: normal (base)
  Storage format:   VHD
  Format variant:   dynamic default
  Location: /root/120g-dyn.vhd
  # VBoxManage showhdinfo 140g-dyn.vhd 
  UUID: 94531905-46b4-469f-bb44-7a7d388fb38f
  Accessible:   yes
  Logical size: 143360 MBytes
  Current size on disk: 0 MBytes
  Type: normal (base)
  Storage format:   VHD
  Format variant:   dynamic default
  Location: /root/140g-dyn.vhd

  # kvm-img convert -f vpc -O raw 120g-dyn.vhd 120g-dyn.img
  #
  # kvm-img convert -f vpc -O raw 140g-dyn.vhd 140g-dyn.img
  #

  # kvm-img info 120g-dyn.img 
  image: 120g-dyn.img
  file format: raw
  virtual size: 120G (128847052800 bytes)
  disk size: 0
  # kvm-img info 120g-dyn.img | grep virtual size
  virtual size: 120G (128847052800 bytes)
  # kvm-img info 140g-dyn.img 
  image: 140g-dyn.img
  file format: raw
  virtual size: 127G (13683600 bytes)
  disk size: 0
  # kvm-img info 140g-dyn.img | grep virtual size
  virtual size: 127G (13683600 bytes)

  Notice after the conversion the raw image will the taken on the
  partial geometry of the vhd, thus rendering that image invalid.

  vboxmanage has a clonehd option which allows you to successfully
  convert vhd to a raw image, which kvm then sees 

[Qemu-devel] [Bug 241119] Re: usb_add of a Creative ZEN unrecognized in guest

[Launchpad Bug Tracker]

[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu-kvm (Ubuntu)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/241119

Title:
  usb_add of a Creative ZEN unrecognized in guest

Status in QEMU:
  Incomplete
Status in “qemu-kvm” package in Ubuntu:
  Expired

Bug description:
  Binary package hint: kvm

  This happens when I add my Creative ZEN to a virtual machine running XP. The 
device is recognised well at first and drivers are installed correctly. But 
when trying to connect windows crashes with the classic blue screen It 
complains about something like usbohci.sys, I can't read well because it 
crashes too fast.
  I have also tried with another virtual machine running Vista, same results.
  Any help would be really appreciated!

  I'm using the module kvm-amd with Ubuntu 8.04

  The USB device has the following ID: 041e:4157 Creative Technology,
  Ltd

  kvm:
Installed: 1:62+dfsg-0ubuntu7
Candidate: 1:62+dfsg-0ubuntu7
Version table:
   *** 1:62+dfsg-0ubuntu7 0
  500 http://archive.ubuntu.com hardy/main Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/241119/+subscriptions

[Qemu-devel] [Bug 611142] Re: seabios should have native scsi support

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: seabios (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/611142

Title:
  seabios should have native scsi support

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Triaged
Status in “seabios” package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: seabios

  Currently when a grub multiboot image is booted with 'kvm -kernel' and
  'biosdisk' module, it will see block devices of type IDE or virtio.
  It will not see scsi devices.

  To demonstrate this:
  $ qemu-img create -f qcow2 disk.img 1G
  $ grub-mkrescue --output=rescue.iso
  $ grub-mkimage -O i386-pc --output=grub-mb.img biosdisk minicmd part_msdos

  An 'ls' inside the grub prompt will show hard disks (hd0) on if:
  a.) -drive uses interface of virtio or scsi
  or
  b.) kvm boots boot from a cdrom or floppy 

  For example, with these commands, grub will see a '(hd0)'
  $ kvm -drive file=disk.img,if=scsi,boot=on -cdrom rescue.iso -boot d
  $ kvm -drive file=disk.img,if=scsi,boot=on -floppy rescue.iso -boot a
  $ kvm -drive file=disk.img,if=virtio,boot=on -cdrom rescue.iso -boot d
  $ kvm -drive file=disk.img,if=ide,boot=on -cdrom rescue.iso -boot d
  $ kvm -drive file=disk.img,if=virtio,boot=on -kernel grub-mb.img 
  $ kvm -drive file=disk.img,if=ide,boot=on -kernel grub-mb.img 

  But the following will not:
  $ kvm -drive file=disk.img,if=scsi,boot=on -kernel grub-mb.img

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: seabios 0.6.0-0ubuntu1
  ProcVersionSignature: User Name 2.6.32-305.9-ec2 2.6.32.11+drm33.2
  Uname: Linux 2.6.32-305-ec2 i686
  Architecture: i386
  Date: Thu Jul 29 03:21:21 2010
  Dependencies:
   
  Ec2AMI: ami-e930db80
  Ec2AMIManifest: 
ubuntu-images-testing-us/ubuntu-maverick-daily-i386-server-20100727.manifest.xml
  Ec2AvailabilityZone: us-east-1b
  Ec2InstanceType: m1.small
  Ec2Kernel: aki-407d9529
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: seabios

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/611142/+subscriptions

[Qemu-devel] [Bug 830558] [NEW] VF doesn't work in guest when not pinned with addr=

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Environment:

Host OS (ia32/ia32e/IA64):All
Guest OS (ia32/ia32e/IA64):ia32e
Guest OS Type (Linux/Windows):Linux (rhel6 and rhel5u5)
kvm.git Commit:ef7c782ea4a99fafb3d60dc8b8c057e0ef14f9f7
qemu-kvm Commit:44755ea36fee3f0b1093ef27404def8857602274
Host Kernel Version:3.0.0+
Hardware: Westmere-EP platform

Bug detailed description:
--
SR-IOV VF NIC doesn't work in guest when not pinned pci address with 
addr=x05. Guest's dmesg shows Failed to initialize MSI-X interrupts.  If 
not pinned an address with addr=0x05, the VF will be pinned to :00:03.0 
by default, and that doesn't work.
Normal vtd NIC assignment doesn't have this issue.
commit:fda19064e  of qemu-kvm.git is good.
commit:44755ea36 of qemu-kvm.git is bad with this issue.
There maybe something wrong between the two commit.
Here's some dmesg info in the guest.
dmesg in guest--
Intel(R) Virtual Function Network Driver - version 1.0.0-k0
Copyright (c) 2009 Intel Corporation.
igbvf :00:03.0: setting latency timer to 64
igbvf :00:03.0: Failed to initialize MSI-X interrupts.
igbvf :00:03.0: Intel(R) 82576 Virtual Function
igbvf :00:03.0: Address: da:66:bb:e6:1e:f4
igbvf :00:03.0: MAC: 1

igbvf :00:03.0: Unable to allocate interrupt, Error: -1


Reproduce steps:

1.pci-stub the a VF in 82576 NIC
2.create a guest: qemu-system-x86_64 -m 1024 -smp 2 -device 
pci-assign,host=01:10.0 -net none -hda /root/rhel6.qcow
(if using '-device pci-assign,host=01:10.0,addr=0x5, the VF will work)
3.check network in guest

Current result:

VF doesn't work in guest.

Expected result:

VF works well in guest.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
VF doesn't work in guest when not pinned with addr=
https://bugs.launchpad.net/bugs/830558
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 739088] [NEW] I/O errors after Save/Restore

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

qemu-kvm commit: b73357ecd2b14c057134cb71d29447b5b988c516
( Author: Marcelo Tosatti mtosa...@redhat.comDate:   Wed Mar 16 17:04:16 
2011 -0300)
kvm commit: a72e315c509376bbd1e121219c3ad9f23973923f

After restoring from saved img, some I/O errors appear in dmesg and file
system is read-only.  I'm sure that the  guest runs normally before
saving. See the pictures attached in detail.

Reproduce steps:

1.create a guest:
  qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 
/root/test0320.img
  qemu-system-x86_64  -m 256  -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 
-net tap,script=/etc/kvm/qemu-ifup -hda /root/test0320.img
2.save the guest: 
  on qemu monitor: migrate exec:dd of=/root/test-save.img
3.quit from qemu: 
  q command on qemu monitor
4.restore from img just saved:
  qemu-system-x86_64  -m 256  -net nic,macaddr=00:16:3e:06:8a:08,model=rtl8139 
-net tap,script=/etc/kvm/qemu-ifup -incoming=/roo/test-save.img
5.see dmesg in restored guest, you'll find some I/O errors. And run some
commands such as ps, touch,reboot and so on. Then some I/O errors appear.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: error io
-- 
I/O errors after Save/Restore
https://bugs.launchpad.net/bugs/739088
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 814222] Re: kvm cannot use vhd files over 127GB

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.14.1+noroms-0ubuntu5

---
qemu-kvm (0.14.1+noroms-0ubuntu5) oneiric; urgency=low

  * debian/patches/vpc.patch: detect vpc files which are too big
(LP: #814222)
 -- Serge Hallyn serge.hal...@ubuntu.com   Mon, 12 Sep 2011 11:28:36 -0500

** Changed in: qemu-kvm (Ubuntu)
   Status: Triaged = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/814222

Title:
  kvm cannot use vhd files over 127GB

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  The primary use case for using vhds with KVM is to perform a
  conversion to a raw image file so that one could move from Hyper-V to
  Linux-KVM.  See more on this http://blog.allanglesit.com/2011/03
  /linux-kvm-migrating-hyper-v-vhd-images-to-kvm/

  # kvm-img convert -f raw -O vpc /root/file.vhd /root/file.img

  The above works great if you have VHDs smaller than 127GB, however if
  it is larger, then no error is generated during the conversion
  process, but it appears to just process up to that 127GB barrier and
  no more.  Also of note.  VHDs can also be run directly using KVM if
  they are smaller than 127GB.  VHDs can be read and function well using
  virtualbox as well as hyper-v, so I suspect the problem lies not with
  the VHD format (since that has a 2TB limitation).  But instead with
  how qemu-kvm is interpreting them.

  BORING VERSION INFO:
  # cat /etc/issue
  Ubuntu 11.04 \n \l
  # uname -rmiv
  2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64
  # apt-cache policy kvm
  kvm:
Installed: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1
Candidate: 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1
Version table:
   *** 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.1 0
  500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages
  500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages
  100 /var/lib/dpkg/status
   1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4 0
  500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages
  # apt-cache policy libvirt-bin
  libvirt-bin:
Installed: 0.8.8-1ubuntu6.2
Candidate: 0.8.8-1ubuntu6.2
Version table:
   *** 0.8.8-1ubuntu6.2 0
  500 http://apt.sonosite.com/ubuntu/ natty-updates/main amd64 Packages
  500 http://apt.sonosite.com/ubuntu/ natty-security/main amd64 Packages
  100 /var/lib/dpkg/status
   0.8.8-1ubuntu6 0
  500 http://apt.sonosite.com/ubuntu/ natty/main amd64 Packages

  qemu-img version 0.14.0

  # vboxmanage -v
  4.0.12r72916

  
  REPRODUCTION STEPS (requires Windows 7 or Windows 2008 R2 with  1GB of free 
space)

  ##  WINDOWS  MACHINE  ##

  Use Computer Management  Disk Management
  -Create 2 VHD files, both dynamically expanding 120GB and 140GB respectively.
  -Do not initialize  or format.

  These files will need to be transferred to an Ubuntu KVM machine (pscp
  is what I used but usb would work as well).

  ##  UBUNTU KVM MACHINE  ##

  # ls *.vhd
  120g-dyn.vhd  140g-dyn.vhd
  # kvm-img info 120g-dyn.vhd 
  image: 120g-dyn.vhd
  file format: vpc
  virtual size: 120G (128847052800 bytes)
  disk size: 244K
  # kvm-img info 140g-dyn.vhd 
  image: 140g-dyn.vhd
  file format: vpc
  virtual size: 127G (13683600 bytes)
  disk size: 284K
  # kvm-img info 120g-dyn.vhd | grep virtual size
  virtual size: 120G (128847052800 bytes)
  # kvm-img info 140g-dyn.vhd | grep virtual size
  virtual size: 127G (13683600 bytes)

  Regardless of how big the second vhd is I always get a virtual size of
  127G

  Now if we use virtualbox to view the vhds we see markedly different
  results.

  # VBoxManage showhdinfo 120g-dyn.vhd
  UUID: e63681e0-ff12-4114-85de-7d13562b36db
  Accessible:   yes
  Logical size: 122880 MBytes
  Current size on disk: 0 MBytes
  Type: normal (base)
  Storage format:   VHD
  Format variant:   dynamic default
  Location: /root/120g-dyn.vhd
  # VBoxManage showhdinfo 140g-dyn.vhd 
  UUID: 94531905-46b4-469f-bb44-7a7d388fb38f
  Accessible:   yes
  Logical size: 143360 MBytes
  Current size on disk: 0 MBytes
  Type: normal (base)
  Storage format:   VHD
  Format variant:   dynamic default
  Location: /root/140g-dyn.vhd

  # kvm-img convert -f vpc -O raw 120g-dyn.vhd 120g-dyn.img
  #
  # kvm-img convert -f vpc -O raw 140g-dyn.vhd 140g-dyn.img
  #

  # kvm-img info 120g-dyn.img 
  image: 120g-dyn.img
  file format: raw
  virtual size: 120G (128847052800 bytes)
  disk size: 0
  # kvm-img info 120g-dyn.img | grep virtual size
  virtual size: 120G (128847052800 bytes)
  # kvm-img info 140g-dyn.img 
  image: 140g-dyn.img
  file format: raw
  virtual size: 127G (13683600 bytes)
  disk size: 0
  # kvm-img info 

[Qemu-devel] [Bug 697197] Re: Empty password allows access to VNC in libvirt

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/lucid-proposed/qemu-kvm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697197

Title:
  Empty password allows access to VNC in libvirt

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Confirmed
Status in qemu-kvm:
  Unknown
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Invalid
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “libvirt” source package in Maverick:
  Invalid
Status in “qemu-kvm” source package in Maverick:
  Fix Released
Status in “libvirt” source package in Natty:
  Invalid
Status in “qemu-kvm” source package in Natty:
  Fix Released
Status in “libvirt” source package in Karmic:
  Invalid
Status in “qemu-kvm” source package in Karmic:
  Fix Released

Bug description:
  The help in the /etc/libvirt/qemu.conf states

  To allow access without passwords, leave this commented out. An empty
  string will still enable passwords, but be rejected by QEMU
  effectively preventing any use of VNC.

  yet setting:

  vnc_password=

  allows access to the vnc console without any password prompt just as
  if it is hashed out completely.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: libvirt-bin 0.8.3-1ubuntu14
  ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8
  Uname: Linux 2.6.35-24-server x86_64
  Architecture: amd64
  Date: Tue Jan  4 12:18:35 2011
  InstallationMedia: Ubuntu-Server 10.04.1 LTS Lucid Lynx - Release amd64 
(20100816.2)
  ProcEnviron:
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libvirt

[Qemu-devel] [Bug 532733] Re: apt/dpkg in qemu-system-arm hangs if a big task is installed

[Launchpad Bug Tracker]

[Expired for qemu-linaro (Ubuntu) because there has been no activity for
60 days.]

** Changed in: qemu-linaro (Ubuntu)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/532733

Title:
  apt/dpkg in qemu-system-arm hangs if a big task is installed

Status in QEMU:
  Invalid
Status in “qemu-linaro” package in Ubuntu:
  Expired
Status in “qemu-linaro” source package in Lucid:
  Expired

Bug description:
  Binary package hint: qemu-kvm

  running rootstock and installing ubuntu-netbook^ makes the VM hang in
  unpacking iso-codes this is reproducable every time in rootstock as
  well as in a standard qemu-system-arm vm that contains a minimal
  ubuntu with running apt-get install ubuntu-netbook

[Qemu-devel] [Bug 532733] Re: apt/dpkg in qemu-system-arm hangs if a big task is installed

[Launchpad Bug Tracker]

[Expired for qemu-linaro (Ubuntu Lucid) because there has been no
activity for 60 days.]

** Changed in: qemu-linaro (Ubuntu Lucid)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/532733

Title:
  apt/dpkg in qemu-system-arm hangs if a big task is installed

Status in QEMU:
  Invalid
Status in “qemu-linaro” package in Ubuntu:
  Expired
Status in “qemu-linaro” source package in Lucid:
  Expired

Bug description:
  Binary package hint: qemu-kvm

  running rootstock and installing ubuntu-netbook^ makes the VM hang in
  unpacking iso-codes this is reproducable every time in rootstock as
  well as in a standard qemu-system-arm vm that contains a minimal
  ubuntu with running apt-get install ubuntu-netbook

[Qemu-devel] [Bug 919242] Re: qemu-img convert to VDI corrupts image

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu6

---
qemu-kvm (1.0+noroms-0ubuntu6) precise; urgency=low

  [ Stefan Weil ]
  * debian/patches/block_vd_zero_unused_parts: Zero unused parts when
allocating a new block (LP: #919242)
 -- Serge Hallyn serge.hal...@ubuntu.com   Mon, 20 Feb 2012 13:33:05 -0600

** Changed in: qemu-kvm (Ubuntu)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/919242

Title:
  qemu-img convert to VDI corrupts image

Status in QEMU:
  Fix Released
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Hello,  thanks to all for the great work on qemu, an excellent
  technology.

  There appears to be a serious bug in qemu-img 1.0, yielding silent
  corruption when converting an image to VDI format.  After conversion
  to  VDI, an image with WinNT4sp6 (NTFS) yields a boot failure (details
  below) -- presumably due to some corruption, since the image works
  fine as the source .vhd (from virtualPC6), and also when converted to
  QCOW2 or VMDK format.

  TEST CASE:
  OS X 10.6.8 on Intel i5
  Qemu 1.0 from mac ports  (macports.org)
  The source BaseDrive.vhd image is from VirtualPC6 (Mac)
  $ qemu-img info BaseDrive.vhd
  image: BaseDrive.vhd
  file format: vpc
  virtual size: 2.0G (2096898048 bytes)
  disk size: 190M

  The image has a fresh Windows NT4sp6 NTFS installation.  It's from VirtualPC6 
(Connectix)  inside a .vhdp package directory on OS X.  Convert via:
qemu-img convert -f vpc -O vdi BaseDrive.vhd  BaseDrive.vdi

  Now run the resulting vdi file with: 
qemu-system-i386 -cpu pentium BaseDrive.vdi
  On boot, NT4 crashes with
  STOP: c26c {Unable to Load Device Driver}
  \??\C:\WINNT\system32\win32k.sys device driver could not be loaded.
  Error Status was 0xc221

  Both qemu 1.0, and VirtualBox 4.1.8 yield the same error on this VDI.

  Conversion of the exact same image to QCOW2 or VMDK format yields a working 
image (ie. qemu and VirtualBox boot fine):
qemu-img convert -f vpc -O qcow2 BaseDrive.vhd  BaseDrive.qcow2
OR
qemu-img convert -f vpc -O vmdk BaseDrive.vhd  BaseDrive.vmdk

  Furthermore, I tested converting from raw, qcow2, and vmdk  to vdi,
  and in all these cases the original format boots, but the converted
  VDI fails to boot as above.

  Along the way, I think I also tested a VDI natively created and
  installed from VirtualBox, which did boot fine in qemu.  Thus the
  problem appears to be not in qemu-system-i386 reading the VDI, rather
  in the qemu-img conversion to VDI.

  
  SEVERITY: CRITICAL
  The severity of this bug is critical as it appears to produce a silently 
corrupted VDI image.  (which is presumably the cause of the boot failure; 
though I have not explicitly check-disked the resulting VDI image).  It also 
impedes easy inter-use between qemu and VirtualBox.

  WORKAROUND:
  The workaround is to use the VMDK format instead of VDI. 
  VMDK is supported by both qemu and VirtualBox (and vmWare).

  
  I can supply a test VHD/QCOW2/VMDK image if desired to reproduce the bug.   
(but it's large, 190M)

  -- jbthiel

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/919242/+subscriptions

[Qemu-devel] [Bug 524447] Re: virsh save is very slow

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu9.18

---
qemu-kvm (0.12.3+noroms-0ubuntu9.18) lucid-proposed; urgency=low

  [ Michael Tokarev ]
  * 
QEMUFileBuffered:-indicate-that-were-ready-when-the-underlying-file-is-ready.diff
   (patch from upstream to speed up migration dramatically)
   (closes: #597517) (LP: #524447)

  [ Serge Hallyn ]
  * debian/control: make qemu-common replace qemu ( 0.12.3+noroms-0ubuntu9.17)
(LP: #592010)
 -- Serge Hallyn serge.hal...@ubuntu.com   Mon, 13 Feb 2012 11:24:18 -0600

** Changed in: qemu-kvm (Ubuntu Lucid)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/524447

Title:
  virsh save is very slow

Status in libvirt virtualization API:
  Unknown
Status in QEMU:
  Fix Released
Status in “libvirt” package in Ubuntu:
  Invalid
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “libvirt” source package in Lucid:
  Won't Fix
Status in “qemu-kvm” source package in Lucid:
  Fix Released
Status in “libvirt” source package in Maverick:
  Won't Fix
Status in “qemu-kvm” source package in Maverick:
  Won't Fix
Status in “qemu-kvm” package in Debian:
  Fix Released

Bug description:
  ==
  SRU Justification:
  1. impact: 'qemu save' is slow
  2. how addressed: a patch upstream fixes the case when a file does not 
announce when it is ready.
  3. patch: see the patch in linked bzr trees
  4. TEST CASE: see comment #4 for a specific recipe
  5. regression potential:  this patch only touches the vm save path.
  ==

  As reported here: http://www.redhat.com/archives/libvir-
  list/2009-December/msg00203.html

  virsh save is very slow - it writes the image at around 1MB/sec on
  my test system.

  (I think I saw a bug report for this issue on Fedora's bugzilla, but I
  can't find it now...)

  Confirmed under Karmic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/524447/+subscriptions

[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu7

---
qemu-kvm (1.0+noroms-0ubuntu7) precise; urgency=low

  [ Dave Walker ]
  * debian/patches/expose_vmx_qemu64cpu.patch: Expose VMX cpuid feature to the
default qemu64 CPU type, supporting Intel compatible VMX nested
virtualization.

  [ Serge Hallyn ]
  * debian/patches/fix-vmware-vga-negative-vals - if x or y  0, set them to 0
(and decrement width/height accordingly)  (LP: #918791)
 -- Serge Hallyn serge.hal...@ubuntu.com   Wed, 14 Mar 2012 14:52:44 -0500

** Changed in: qemu-kvm (Ubuntu Precise)
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/918791

Title:
  qemu-kvm dies when using vmvga driver and unity in the guest

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “xserver-xorg-video-vmware” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” source package in Precise:
  Fix Released
Status in “xserver-xorg-video-vmware” source package in Precise:
  Confirmed

Bug description:
  12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I
  figured out it has something to do with the interaction of qemu-kvm,
  unity and the vmvga driver. This is a regression over qemu-kvm in
  11.10.

  TEST CASE:
  1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use 
unity-2d on an amd64 host and amd64 guests
  2. on 11.04 and 11.10, open empathy via the messaging indicator and click 
'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', 
close the empathy wizard, move the empathy window over the unity luancher (so 
it autohides), then do 'ctrl+alt+t' to open a terminal

  When the launcher tries to auto(un)hide, qemu-kvm dies with this:
  [10574.958149] do_general_protection: 132 callbacks suppressed
  [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 
error:0 in qemu-system-x86_64[7fab966c4000+2c9000]

  Relevant libvirt xml:
  video
model type='vmvga' vram='9216' heads='1'/
address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
  /video

  If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg:
  video
model type='cirrus' vram='9216' heads='1'/
alias name='video0'/
address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
  /video

  The workaround is therefore to use the cirrus driver instead of vmvga,
  however being able to kill qemu-kvm in this manner is not ideal. Also,
  unfortunately unity-2d does not run with with cirrus driver under
  11.04, so the security and SRU teams are unable to properly test
  updates in GUI applications under unity when using the current 12.04
  qemu-kvm.

  I tried to report this via apport, but apport complained about a CRC
  error, so I could not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/918791/+subscriptions

[Qemu-devel] [Bug 932539] Re: qemu exits with -11 when connecting to a port redirect before the service starts listening

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu8

---
qemu-kvm (1.0+noroms-0ubuntu8) precise; urgency=low

  * debian/patches/slirp-*: fix bad exit with -11 when connecting to a port
redirect before the service starts listening.  (LP: #932539)
 -- Serge Hallyn serge.hal...@ubuntu.com   Fri, 16 Mar 2012 16:34:05 -0500

** Changed in: qemu-kvm (Ubuntu)
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/932539

Title:
  qemu exits with -11 when connecting to a port redirect before the
  service starts listening

Status in QEMU:
  Fix Released
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  This was detected initially as a crash in the auto upgrade tester.
  The code of the upgrade tester basically spawns a kvm instance in the 
background with a port redirect from localhost:54322 to tcp:22 in the VM, then 
wait for that port to allow for a ssh connection before continuing the upgrade 
testing.

  In the past (Oneiric), all worked well but since Precise, we now get
  qemu exitting with -11 at every single test :(

  A quick reproducer is:
   - start a VM that has openssh-server installed with: -net 
user,hostfwd=tcp::54322-:22
   - immediately start ssh -p 54322 127.0.0.1 before the VM starts booting 
(BIOS/GRUB state)

  Then wait for sshd to start in the VM and qemu will exit with -11.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/932539/+subscriptions

[Qemu-devel] [Bug 957622] Re: kvm -kernel with grub multiboot kernel dumps core or exits

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu9

---
qemu-kvm (1.0+noroms-0ubuntu9) precise; urgency=low

  * debian/patches/multiboot-load-fix.diff: fix bug when loading
multiboot images such as grub via -kernel parameter (LP: #957622)
 -- Scott Moser smo...@ubuntu.com   Sun, 18 Mar 2012 19:34:28 -0400

** Changed in: qemu-kvm (Ubuntu)
   Status: In Progress = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/957622

Title:
  kvm -kernel with grub multiboot kernel dumps core or exits

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  I attempted to use kvm -kernel with a grub multiboot image,
  specifically grub-maverick-20100729.img at [1].  That file was built
  using [2]

  $ 
url=http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/download/head:/grubmaverick20100729-20100729071944-bevge631maio9jpl-2/grub-maverick-20100729.img;
  $ wget $url -O grub-maverick-20100729.img
  $ qemu-img create -f qcow2 disk.img 1G
  $ kvm -curses -kernel grub-maverick-20100729.img -drive 
file=disk.img,if=virtio

  This process works fine on oneiric and you will see a curses
  interface, and some output of grub looking for a image to boot.

  On my laptop (with kvm support), I saw:

  $ kvm -curses -kernel grub-maverick-20100729.img -drive 
file=disk.img,if=virtio;
  fread() failed
  $ echo $?
  1

  On a kvm guest (via openstack instance), it crashed differently:
  $ kvm -curses -kernel grub-maverick-20100729.img -drive 
file=disk.img,if=virtio
  Could not access KVM kernel module: No such file or directory
  failed to initialize KVM: No such file or directory
  Back to tcg accelerator.

  GLib-ERROR **: /build/buildd/glib2.0-2.31.20/./glib/gmem.c:165: failed to 
allocate 4293918720 bytes
  Trace/breakpoint trap (core dumped)

  Just for a test, I tried loading kvm-amd, got nested kvm
  virtualization, but the instance fails the same way.

  --
  [1] 
http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/files/head:/loaders/
  [2] 
http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/mk-image-mb-loader

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: kvm (not installed)
  ProcVersionSignature: User Name 3.2.0-18.29-virtual 3.2.9
  Uname: Linux 3.2.0-18-virtual x86_64
  ApportVersion: 1.94.1-0ubuntu2
  Architecture: amd64
  CurrentDmesg:
   [27230.320857] init: qemu-kvm pre-start process (8659) terminated with 
status 1
   [27230.361904] init: qemu-kvm post-stop process (8664) terminated with 
status 1
   [27249.426836] kvm[9021] trap int3 ip:7f44c2bbc13b sp:7fff447e1120 error:0
   [27263.380598] kvm[9283] trap int3 ip:7f3fba9f713b sp:7fff8b55d1a0 error:0
  Date: Sat Mar 17 01:48:13 2012
  Ec2AMI: ami-
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
  Lsusb:
   Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd
  MachineType: Bochs Bochs
  ProcEnviron:
   TERM=screen
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-virtual 
root=LABEL=cloudimg-rootfs ro console=ttyS0
  ProcModules:
   acpiphp 24231 0 - Live 0x
   floppy 70365 0 - Live 0x
   psmouse 87603 0 - Live 0x
   serio_raw 13211 0 - Live 0x
   virtio_balloon 13108 0 - Live 0x
  SourcePackage: qemu-kvm
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/01/2007
  dmi.bios.vendor: Bochs
  dmi.bios.version: Bochs
  dmi.chassis.type: 1
  dmi.chassis.vendor: Bochs
  dmi.modalias: 
dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr:
  dmi.product.name: Bochs
  dmi.sys.vendor: Bochs

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/957622/+subscriptions

[Qemu-devel] [Bug 1052380] Re: qemu 1.0.50-2012.03-0ubuntu2 makes ARMv6k kernels crash

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/qemu-linaro

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1052380

Title:
  qemu 1.0.50-2012.03-0ubuntu2 makes ARMv6k kernels crash

Status in QEMU:
  Fix Released
Status in “qemu-linaro” package in Ubuntu:
  New

Bug description:
  The Linux ARM kernel commit that starts causing the issue is:
  18b9dc130c33de2d1fd46bd668e67d0e1a544b16: ARM: vfp: add VFPv4 capability 
detection and populate elf_hwcap

  And is fixed in qemu with:
  06ed5d66f77f2794344c7dfd3d21a07e97f0b8fa: ARM: Permit any ARMv6K CPU to read 
the MVFR0 and MVFR1 VFP registers.

  qemu should be updated to at least v1.1.0 as soon as possible because
  all ARM realview kernels  3.0 with VFP enabled will suffer from this
  issue.

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1052380/+subscriptions

[Qemu-devel] [Bug 1052380] Re: qemu 1.0.50-2012.03-0ubuntu2 makes ARMv6k kernels crash

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-linaro - 1.2.0-2012.09-0ubuntu1

---
qemu-linaro (1.2.0-2012.09-0ubuntu1) quantal; urgency=low

  [ Fathi Boudra ]
  * FFe for new upstream version (LP: #1053212)
- Compatibility with ARM realview kernels  3.0 with VFP (LP: #1052380)
  * Also pass -fno-var-tracking on armhf

  [ Ricardo Salveti de Araujo ]
  * Bump to standards 3.9.3
 -- Ricardo Salveti de Araujo ricardo.salv...@linaro.org   Thu, 20 Sep 2012 
15:52:57 -0300

** Changed in: qemu-linaro (Ubuntu)
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1052380

Title:
  qemu 1.0.50-2012.03-0ubuntu2 makes ARMv6k kernels crash

Status in QEMU:
  Fix Released
Status in “qemu-linaro” package in Ubuntu:
  Fix Released

Bug description:
  The Linux ARM kernel commit that starts causing the issue is:
  18b9dc130c33de2d1fd46bd668e67d0e1a544b16: ARM: vfp: add VFPv4 capability 
detection and populate elf_hwcap

  And is fixed in qemu with:
  06ed5d66f77f2794344c7dfd3d21a07e97f0b8fa: ARM: Permit any ARMv6K CPU to read 
the MVFR0 and MVFR1 VFP registers.

  qemu should be updated to at least v1.1.0 as soon as possible because
  all ARM realview kernels  3.0 with VFP enabled will suffer from this
  issue.

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1052380/+subscriptions

[Qemu-devel] [Bug 918791] Re: qemu-kvm dies when using vmvga driver and unity in the guest

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: xserver-xorg-video-vmware (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/918791

Title:
  qemu-kvm dies when using vmvga driver and unity in the guest

Status in QEMU:
  New
Status in “qemu-kvm” package in Ubuntu:
  Confirmed
Status in “xserver-xorg-video-vmware” package in Ubuntu:
  Confirmed
Status in “qemu-kvm” source package in Precise:
  Confirmed
Status in “xserver-xorg-video-vmware” source package in Precise:
  Confirmed

Bug description:
  12.04's qemu-kvm has been unstable for me and Marc Deslauriers and I
  figured out it has something to do with the interaction of qemu-kvm,
  unity and the vmvga driver. This is a regression over qemu-kvm in
  11.10.

  TEST CASE:
  1. start a VM that uses unity (eg, 11.04, 11.10 or 12.04). My tests use 
unity-2d on an amd64 host and amd64 guests
  2. on 11.04 and 11.10, open empathy via the messaging indicator and click 
'Chat'. On 12.04, open empathy via the messaging indicator and click 'Chat', 
close the empathy wizard, move the empathy window over the unity luancher (so 
it autohides), then do 'ctrl+alt+t' to open a terminal

  When the launcher tries to auto(un)hide, qemu-kvm dies with this:
  [10574.958149] do_general_protection: 132 callbacks suppressed
  [10574.958154] kvm[13192] general protection ip:7fab9680ea0f sp:74440148 
error:0 in qemu-system-x86_64[7fab966c4000+2c9000]

  Relevant libvirt xml:
  video
model type='vmvga' vram='9216' heads='1'/
address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
  /video

  If I change to using 'cirrus', then qemu-kvm no longer crashes. Eg:
  video
model type='cirrus' vram='9216' heads='1'/
alias name='video0'/
address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
  /video

  The workaround is therefore to use the cirrus driver instead of vmvga,
  however being able to kill qemu-kvm in this manner is not ideal. Also,
  unfortunately unity-2d does not run with with cirrus driver under
  11.04, so the security and SRU teams are unable to properly test
  updates in GUI applications under unity when using the current 12.04
  qemu-kvm.

  I tried to report this via apport, but apport complained about a CRC
  error, so I could not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/918791/+subscriptions

[Qemu-devel] [Bug 571432] Re: qemu-system-arm crashed with SIGSEGV in subpage_register()

[Launchpad Bug Tracker]

[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu-kvm (Ubuntu)
   Status: Incomplete = Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/571432

Title:
  qemu-system-arm crashed with SIGSEGV in subpage_register()

Status in QEMU:
  Incomplete
Status in “qemu-kvm” package in Ubuntu:
  Expired

Bug description:
  Binary package hint: qemu-kvm

  i think this is the crash behind Bug #570588 not sure why apport did
  not trigger before

  ProblemType: Crash
  DistroRelease: Ubuntu 10.04
  Package: qemu-kvm-extras 0.12.3+noroms-0ubuntu9
  ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
  Uname: Linux 2.6.32-21-generic x86_64
  NonfreeKernelModules: openafs
  Architecture: amd64
  Date: Wed Apr 28 21:30:13 2010
  ExecutablePath: /usr/bin/qemu-system-arm
  InstallationMedia: Ubuntu 9.10 Karmic Koala - Release amd64 (20091027)
  KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
  ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-21-generic 
root=UUID=52d7f930-7148-4978-825e-71fcb9243ac6 ro quiet splash
  ProcCmdline: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel 
/tmp/tmp.B2CtSo2g2u/qemu-vmlinuz -no-reboot -nographic -pidfile 
/tmp/tmp.B2CtSo2g2u/qemu.pid -drive 
file=/tmp/tmp.B2CtSo2g2u/qemu-armel-201004282122.img,aio=native,cache=none -m 
512 -append console=ttyAMA0,115200n8\ root=/dev/sda\ rw\ mem=256M\ 
devtmpfs.mount=0\ init=/bin/installer\ quiet
  ProcEnviron:
   SHELL=/bin/bash
   LANG=en_GB.UTF-8
  SegvAnalysis:
   Segfault happened at: 0x51058e subpage_register+158:   cmpq   
$0x0,(%rdx)
   PC (0x0051058e) ok
   source $0x0 ok
   destination (%rdx) (0x40cc28c0) not located in a known VMA region (needed 
writable region)!
  SegvReason: writing unknown VMA
  Signal: 11
  SourcePackage: qemu-kvm
  StacktraceTop:
   subpage_register (mmio=0x7f841b26d010, start=value optimised out, 
   subpage_init (base=268500992, phys=0x1d47400, 
   cpu_register_physical_memory_offset (
   smc91c111_init (nd=0xc41b60, base=1087121600, 
   versatile_init (ram_size=value optimised out,
  Title: qemu-system-arm crashed with SIGSEGV in subpage_register()
  UserGroups:
   
  dmi.bios.date: 11/07/2007
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: S2696
  dmi.board.vendor: Tyan Computer Corporation
  dmi.chassis.type: 6
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd11/07/2007:svn:pn:pvr:rvnTyanComputerCorporation:rnS2696:rvr:cvn:ct6:cvr:

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/571432/+subscriptions

[Qemu-devel] [Bug 1162644] Re: qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base()

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: qemu (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1162644

Title:
  qemu-system-x86_64 crashed with SIGABRT in __assert_fail_base()

Status in QEMU:
  New
Status in “qemu” package in Ubuntu:
  Confirmed

Bug description:
  Description:
  When QEMU tries to boot with a usb 3.0 tablet (xhci) on a Raring ringtail box 
(QEMU package1.4.0+dfsg-1expubuntu4)  it will crash soon afterwards:

  qemu-system-x86_64: /build/buildd/qemu-1.4.0+dfsg/hw/usb/core.c:552:
  usb_packet_setup: Assertion `p-iov.iov != ((void *)0)' failed.

  Component:
  qemu-system - 1.4.0+dfsg-1expubuntu4

  Ubuntu Version:

  Description:  Ubuntu Raring Ringtail (development branch)
  Release:  13.04

  Steps to reproduce it:

  I met this bug while running the virt-test suite

  https://github.com/autotest/virt-test

  Instructions to install and run it can be seen on the README file

  https://github.com/autotest/virt-test#readme

  After the suite is set, it can be reproduced on a raring (13.04)
  simply by running:

  ./run -t qemu --tests usb.usb_reboot.usb_tablet.xhci

  Command line:

  23:52:42 INFO | Running qemu command (reformatted):
  /usr/bin/kvm \
  -S \
  -name 'virt-tests-vm1' \
  -nodefaults \
  -chardev 
socket,id=hmp_id_hmp1,path=/tmp/monitor-hmp1-20130331-233911-ndvUEvrV,server,nowait
 \
  -mon chardev=hmp_id_hmp1,mode=readline \
  -chardev 
socket,id=serial_id_serial1,path=/tmp/serial-serial1-20130331-233911-ndvUEvrV,server,nowait
 \
  -device isa-serial,chardev=serial_id_serial1 \
  -chardev 
socket,id=seabioslog_id_20130331-233911-ndvUEvrV,path=/tmp/seabios-20130331-233911-ndvUEvrV,server,nowait
 \
  -device 
isa-debugcon,chardev=seabioslog_id_20130331-233911-ndvUEvrV,iobase=0x402 \
  -device ich9-usb-uhci1,id=usb1 \
  -device nec-usb-xhci,id=usbtest \
  -drive 
file='/home/lmr/Code/virt-test.git/shared/data/images/jeos-17-64.qcow2',if=none,id=virtio0
 \
  -device virtio-blk-pci,drive=virtio0,bootindex=1 \
  -device 
virtio-net-pci,netdev=idumV1TE,mac='9a:c0:c1:c2:c3:c4',id='idmN7iHv' \
  -netdev user,id=idumV1TE,hostfwd=tcp::5000-:22 \
  -m 1024 \
  -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
  -cpu 'SandyBridge' \
  -M pc \
  -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
  -device usb-tablet,id=usb-testdev,bus=usbtest.0,port=1 \
  -vnc :0 \
  -vga std \
  -rtc base=utc,clock=host,driftfix=none  \
  -boot order=cdn,once=c,menu=off  \
  -enable-kvm

  ProblemType: Crash
  DistroRelease: Ubuntu 13.04
  Package: qemu-system-x86 1.4.0+dfsg-1expubuntu4
  ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4
  Uname: Linux 3.8.0-15-generic x86_64
  ApportVersion: 2.9.2-0ubuntu5
  Architecture: amd64
  Date: Sun Mar 31 23:52:46 2013
  EcryptfsInUse: Yes
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2013-03-31 (0 days ago)
  InstallationMedia: Ubuntu 12.10 Quantal Quetzal - Release amd64 (20121017.5)
  MarkForUpload: True
  ProcEnviron:
   TERM=dumb
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=set
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   raise () from /lib/x86_64-linux-gnu/libc.so.6
   abort () from /lib/x86_64-linux-gnu/libc.so.6
   ?? () from /lib/x86_64-linux-gnu/libc.so.6
   __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
   ?? ()
  Title: qemu-system-x86_64 crashed with SIGABRT in raise()
  UpgradeStatus: Upgraded to raring on 2013-03-31 (0 days ago)
  UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1162644/+subscriptions

[Qemu-devel] [Bug 1077838] Re: qemu-nbd -r -c taints device for subsequent usage, even after -d

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.2.0+noroms-0ubuntu4

---
qemu-kvm (1.2.0+noroms-0ubuntu4) raring; urgency=low

  [ Serge Hallyn ]
  * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as
recommended by Steve Langasek (LP: #1057024)
  * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to
make read-write mount after read-only mount work.  (LP: #1077838)

  [ Robert Collins ]
  * Fix upstart job to succeed if ksm settings can't be altered in the same way
other settings are handled. (LP: #1078530)
 -- Serge Hallyn serge.hal...@ubuntu.com   Wed, 14 Nov 2012 11:30:14 -0600

** Changed in: qemu-kvm (Ubuntu)
   Status: In Progress = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1077838

Title:
  qemu-nbd -r -c taints device for subsequent usage, even after -d

Status in QEMU:
  In Progress
Status in “qemu-kvm” package in Ubuntu:
  Fix Released

Bug description:
  Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind -
  subsequent connections get marked readonly.

  This is on quantal, haven't checked precise or raring.

  To demonstrate:
  # use one image
  qemu-img create -f qcow2 /tmp/1.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # use a second one on the same nbd device, shows that reuse works:
  qemu-img create -f qcow2 /tmp/2.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # connect an image in read only mode
  sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2
  sudo dumpe2fs /dev/nbd2 | head -n 3
  sudo qemu-nbd -d /dev/nbd2
  # now try to reuse in read-write mode again:
  qemu-img create -f qcow2 /tmp/3.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  # here it goes boom:
  mke2fs 1.42.5 (29-Jul-2012)
  /dev/nbd2: Operation not permitted while setting up superblock
  # still need to cleanup
  sudo qemu-nbd -d /dev/nbd2

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1077838/+subscriptions

[Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: qemu-linaro (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

Status in QEMU:
  New
Status in Linaro QEMU:
  New
Status in “qemu-linaro” package in Ubuntu:
  Confirmed

Bug description:
  I'm using git commit 3e7ecd976b06f... configured with --target-list
  =arm-linux-user --static in a chroot environment to compile some
  things. I ran into this problem with both pcl and opencv-2.3.1. cmake
  consistently freezes at some point during its execution, though in a
  different spot each time, usually during a step when it's searching
  for some libraries. For instance, pcl most commonly stops after:

  [snip]
  -- Boost version: 1.46.1
  -- Found the following Boost libraries:
  --   system
  --   filesystem
  --   thread
  --   date_time
  -- checking for module 'eigen3'
  --   found eigen3, version 3.0.1

  which is perplexing because it freezes after finding what it wants,
  not during the search. When it does get past that point, it does so
  almost immediately but freezes somewhere else.

  I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic
  with an Intel i5.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

[Qemu-devel] [Bug 1180970] Re: qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92

[Launchpad Bug Tracker]

** Branch linked: lp:~3v1n0/unity/gtk-wrapper-icon-info

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1180970

Title:
  qemu: fatal: Trying to execute code outside RAM or ROM; worked in
  1.4.0, fails in 1.4.92

Status in QEMU:
  New

Bug description:
  I'm using qemu to run and debug the EDK2 uEFI environment. OVMF is
  being built out of the EDK2 tree I've checked out (r14367).
  (Reproducing all this could be tedious so I am available for
  debugging/testing.)

  qemu 1.4.0 was able to execute this guest environment with no trouble,
  qemu 1.4.92 however issues an error message and aborts.  The command
  line I use to start qemu is:

  $ /usr/local/bin/qemu-system-x86_64 -m 1024 -bios OVMF.fd -monitor
  stdio

  1.4.92 gives the following register dump:

  QEMU 1.4.92 monitor - type 'help' for more information
  (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 
0x0001

  RAX=3e084da8 RBX=3e084868 RCX= 
RDX=3e084f00
  RSI=0001 RDI=3e085000 RBP=3e084708 
RSP=3fac8510
  R8 = R9 =3e14c3e3 R10=0033 
R11=00d3
  R12=3e0848a0 R13= R14= 
R15=
  RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
  ES =0008   00cf9300 DPL=0 DS   [-WA]
  CS =0028   00af9b00 DPL=0 CS64 [-RA]
  SS =0008   00cf9300 DPL=0 DS   [-WA]
  DS =0008   00cf9300 DPL=0 DS   [-WA]
  FS =0008   00cf9300 DPL=0 DS   [-WA]
  GS =0008   00cf9300 DPL=0 DS   [-WA]
  LDT=   8200 DPL=0 LDT
  TR =   8b00 DPL=0 TSS64-busy
  GDT= 3fa50e98 003f
  IDT= 3f9d6e20 0fff
  CR0=8033 CR2= CR3=3fa67000 CR4=0668
  ...

  
  Questions:
  1) Is this problem relevant?  (is full backward compatability to be 
supported?)
  2) Are there new guest execution controls in 1.4.9x that might cause this?
  3) If #2, can they be disabled by a qemu command line switch?
  4) If not #2, in what qemu source file specifically can I find the logic 
causing the abort? (help me help you :)
  5) If guest memory is corrupted or improperly mapped, how can I keep qemu 
alive to examime/dump guest memory?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1180970/+subscriptions

[Qemu-devel] [Bug 1077838] Re: qemu-nbd -r -c taints device for subsequent usage, even after -d

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/raring-proposed/qemu

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1077838

Title:
  qemu-nbd -r -c taints device for subsequent usage, even after -d

Status in QEMU:
  In Progress
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Precise:
  Fix Committed
Status in “qemu-kvm” source package in Quantal:
  Fix Committed

Bug description:
  Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind -
  subsequent connections get marked readonly.

  This is on quantal, haven't checked precise or raring.

  To demonstrate:
  # use one image
  qemu-img create -f qcow2 /tmp/1.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # use a second one on the same nbd device, shows that reuse works:
  qemu-img create -f qcow2 /tmp/2.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # connect an image in read only mode
  sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2
  sudo dumpe2fs /dev/nbd2 | head -n 3
  sudo qemu-nbd -d /dev/nbd2
  # now try to reuse in read-write mode again:
  qemu-img create -f qcow2 /tmp/3.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  # here it goes boom:
  mke2fs 1.42.5 (29-Jul-2012)
  /dev/nbd2: Operation not permitted while setting up superblock
  # still need to cleanup
  sudo qemu-nbd -d /dev/nbd2

  ===
  SRU Justification:
  1. Impact: mounting an nbd device as read-write after doing so read-only
  will cause the mount to erroneously (and quietly) be read-only.
  2. Development fix: have qemu-nbd set the device to read-write when asked,
  rather than only setting read-only.
  3. Stable fix: same as development fix
  4. Test case: See above
  5. Regression potential: The patch is localized to the handling of read-only
  flag in qemu-nbd, so any regression should not affect anything else.
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1077838/+subscriptions

[Qemu-devel] [Bug 1077838] Re: qemu-nbd -r -c taints device for subsequent usage, even after -d

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.2.0+noroms-
0ubuntu2.12.10.1

---
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.1) quantal-proposed; urgency=low

  [ Serge Hallyn ]
  * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as
recommended by Steve Langasek (LP: #1057024)
  * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to
make read-write mount after read-only mount work.  (LP: #1077838)
  * make qemu-kvm depend on udev (LP: #1080912)

  [ Robert Collins ]
  * Fix upstart job to succeed if ksm settings can't be altered in the same way
other settings are handled. (LP: #1078530)
 -- Serge Hallyn serge.hal...@ubuntu.com   Mon, 19 Nov 2012 09:15:42 -0600

** Changed in: qemu-kvm (Ubuntu Quantal)
   Status: Fix Committed = Fix Released

** Changed in: qemu-kvm (Ubuntu Precise)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1077838

Title:
  qemu-nbd -r -c taints device for subsequent usage, even after -d

Status in QEMU:
  In Progress
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Precise:
  Fix Released
Status in “qemu-kvm” source package in Quantal:
  Fix Released

Bug description:
  Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind -
  subsequent connections get marked readonly.

  This is on quantal, haven't checked precise or raring.

  To demonstrate:
  # use one image
  qemu-img create -f qcow2 /tmp/1.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # use a second one on the same nbd device, shows that reuse works:
  qemu-img create -f qcow2 /tmp/2.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # connect an image in read only mode
  sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2
  sudo dumpe2fs /dev/nbd2 | head -n 3
  sudo qemu-nbd -d /dev/nbd2
  # now try to reuse in read-write mode again:
  qemu-img create -f qcow2 /tmp/3.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  # here it goes boom:
  mke2fs 1.42.5 (29-Jul-2012)
  /dev/nbd2: Operation not permitted while setting up superblock
  # still need to cleanup
  sudo qemu-nbd -d /dev/nbd2

  ===
  SRU Justification:
  1. Impact: mounting an nbd device as read-write after doing so read-only
  will cause the mount to erroneously (and quietly) be read-only.
  2. Development fix: have qemu-nbd set the device to read-write when asked,
  rather than only setting read-only.
  3. Stable fix: same as development fix
  4. Test case: See above
  5. Regression potential: The patch is localized to the handling of read-only
  flag in qemu-nbd, so any regression should not affect anything else.
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1077838/+subscriptions

[Qemu-devel] [Bug 1077838] Re: qemu-nbd -r -c taints device for subsequent usage, even after -d

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu14.6

---
qemu-kvm (1.0+noroms-0ubuntu14.6) precise-proposed; urgency=low

  * Fix qemu-kvm.upstart: just don't run in a container.  Otherwise we'll
still try to load/unload kernel modules.  Also undo the || true after
sysfs writes.  Since setting those is a part of configuring qemu-kvm
on the host, failing when they fail makes sense.

qemu-kvm (1.0+noroms-0ubuntu14.5) precise-proposed; urgency=low

  * add udev to qemu-kvm Depends to ensure that postinst succeeds.
(LP: #1080912)

qemu-kvm (1.0+noroms-0ubuntu14.4) precise-proposed; urgency=low

  [ Serge Hallyn ]
  * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as
recommended by Steve Langasek (LP: #1057024)
  * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to
make read-write mount after read-only mount work.  (LP: #1077838)

  [ Robert Collins ]
  * Fix upstart job to succeed if ksm settings can't be altered in the same way
other settings are handled. (LP: #1078530)
 -- Serge Hallyn serge.hal...@ubuntu.com   Thu, 20 Dec 2012 12:34:52 -0600

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1077838

Title:
  qemu-nbd -r -c taints device for subsequent usage, even after -d

Status in QEMU:
  In Progress
Status in “qemu-kvm” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” source package in Precise:
  Fix Released
Status in “qemu-kvm” source package in Quantal:
  Fix Released

Bug description:
  Something about qemu-nbd -r -c /dev/nbd0 someimg leaves cruft behind -
  subsequent connections get marked readonly.

  This is on quantal, haven't checked precise or raring.

  To demonstrate:
  # use one image
  qemu-img create -f qcow2 /tmp/1.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/1.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # use a second one on the same nbd device, shows that reuse works:
  qemu-img create -f qcow2 /tmp/2.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/2.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  sudo qemu-nbd -d /dev/nbd2
  # connect an image in read only mode
  sudo qemu-nbd -r -c /dev/nbd2 /tmp/2.qcow2
  sudo dumpe2fs /dev/nbd2 | head -n 3
  sudo qemu-nbd -d /dev/nbd2
  # now try to reuse in read-write mode again:
  qemu-img create -f qcow2 /tmp/3.qcow2 100M
  sudo qemu-nbd -c /dev/nbd2 /tmp/3.qcow2
  sudo mkfs -t ext4 /dev/nbd2
  # here it goes boom:
  mke2fs 1.42.5 (29-Jul-2012)
  /dev/nbd2: Operation not permitted while setting up superblock
  # still need to cleanup
  sudo qemu-nbd -d /dev/nbd2

  ===
  SRU Justification:
  1. Impact: mounting an nbd device as read-write after doing so read-only
  will cause the mount to erroneously (and quietly) be read-only.
  2. Development fix: have qemu-nbd set the device to read-write when asked,
  rather than only setting read-only.
  3. Stable fix: same as development fix
  4. Test case: See above
  5. Regression potential: The patch is localized to the handling of read-only
  flag in qemu-nbd, so any regression should not affect anything else.
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1077838/+subscriptions

[Qemu-devel] [Bug 1033727] Re: USB passthrough doesn't work anymore with qemu-kvm 1.1.1

[Launchpad Bug Tracker]

This bug was fixed in the package qemu-kvm - 1.2.0+noroms-
0ubuntu2.12.10.3

---
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.3) quantal-proposed; urgency=low

  [ Nikolaus Rath ]
  * fix-usb-passthrough.patch: fix problems with accessing some host
USB devices (Closes: 683983) (LP: #1033727)
 -- Serge Hallyn serge.hal...@ubuntu.com   Tue, 29 Jan 2013 22:26:54 -0600

** Changed in: qemu-kvm (Ubuntu Quantal)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1033727

Title:
  USB passthrough doesn't work anymore with qemu-kvm 1.1.1

Status in QEMU:
  Fix Released
Status in “qemu” package in Ubuntu:
  Fix Released
Status in “qemu-kvm” package in Ubuntu:
  Invalid
Status in “qemu-kvm” source package in Quantal:
  Fix Released
Status in “qemu” source package in Raring:
  Fix Released
Status in “qemu-kvm” package in Debian:
  Fix Released

Bug description:
  
  SRU Justification:
  1. Impact: usb devices which worked with qemu previously stop working
  2. Development fix: a patch upstream entitled uhci: Don't queue up packets 
after one with the SPD flag set fixes the problem
  3. Stable fix: same patch as development fix.
  4. Test case: you must test with certain usb devices - see below for the 
exact kvm arguments to use.
  5. Regression potential: this patch is cherrypicked from upstream so should 
be safe.
  

  Hi,

  I have a Bus 006 Device 002: ID 0d46:3003 Kobil Systems GmbH mIDentity Light 
/ KAAN SIM III (kind of smart card) in an USB port which I make available to a 
Windows XP guest.
  This worked fine with every older qemu-kvm version I've used so far.

  But since 1.1.0 it doesn't work anymore.
  The device shows up in the guest, but the software can't access it anymore 
(and the guest is pretty unresponsive).

  On the host I get every 2 seconds this message:
  [ 7719.239528] usb 6-1: reset full-speed USB device number 2 using uhci_hcd

  Command line options are:
  /usr/bin/kvm
  ...
  -device usb-host,vendorid=0x0d46,productid=0x3003,bus=usb.0,port=3
  ...

  When I switch back to qemu-kvm 1.0.1 everything works fine again.
  Any idea what the problem could be?

  Thanks
  Klaus

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1033727/+subscriptions

[Qemu-devel] [Bug 1303926] Re: qemu-system-x86_64 crashed with SIGABRT

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.0.0~rc1+dfsg-0ubuntu3

---
qemu (2.0.0~rc1+dfsg-0ubuntu3) trusty; urgency=medium

  * d/p/ubuntu/kvm_physical_sync_dirty_bitmap-ignore-ENOENT-from-kv.patch
don't abort() just because the kernel has no dirty bitmap.
(LP: #1303926)
 -- Serge Hallyn serge.hal...@ubuntu.com   Tue, 08 Apr 2014 22:32:00 -0500

** Changed in: qemu (Ubuntu)
   Status: Triaged = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1303926

Title:
  qemu-system-x86_64 crashed with SIGABRT

Status in QEMU:
  New
Status in “qemu” package in Ubuntu:
  Fix Released

Bug description:
  I've been getting this periodically since my upgrade to qemu 2.0 in
  trusty this morning.

  ProblemType: Crash
  DistroRelease: Ubuntu 14.04
  Package: qemu-system-x86 2.0.0~rc1+dfsg-0ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8
  Uname: Linux 3.13.0-23-generic x86_64
  ApportVersion: 2.14.1-0ubuntu1
  Architecture: amd64
  Date: Mon Apr  7 13:31:53 2014
  ExecutablePath: /usr/bin/qemu-system-x86_64
  InstallationDate: Installed on 2013-11-26 (131 days ago)
  InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 
(20131016.1)
  ProcEnviron: PATH=(custom, no user)
  Registers: No symbol table is loaded.  Use the file command.
  Signal: 6
  SourcePackage: qemu
  StacktraceTop:
   
  Title: qemu-system-x86_64 crashed with SIGABRT
  UpgradeStatus: Upgraded to trusty on 2014-01-17 (79 days ago)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1303926/+subscriptions

[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: qemu (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1307473

Title:
  guest hang due to missing clock interrupt

Status in QEMU:
  New
Status in “qemu” package in Ubuntu:
  Confirmed

Bug description:
  
  I noticed on 2 different systems that after upgrade from precise to latest 
trusty VMs are crashing:

  - in case of Windows VMs I'm getting BSOD with error message: A clock 
interrupt was not received on a secondary processor within the allocated time 
interval.
  - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages 
  - On some proprietary virtual appliances I'm noticing crashes an due to 
missing timer interrupts

  QEMU version is:
  QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3)

  Full command line:

  qemu-system-x86_64 -enable-kvm -name win7eval -S -machine pc-
  i440fx-1.7,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off
  -smp 4,sockets=1,cores=4,threads=1 -uuid 05e5089a-
  4aa1-6bb2-ef06-ab4d020a -no-user-config -nodefaults -chardev
  
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7eval.monitor,server,nowait
  -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
  -no-shutdown -boot strict=on -device piix3-usb-
  uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
  file=/var/vm/win7eval.qcow2,if=none,id=drive-virtio-disk0,format=qcow2
  -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-
  disk0,id=virtio-disk0,bootindex=1 -drive
  file=/home/damarion/iso/7600.16385.090713-1255_x86fre_enterprise_en-
  us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive-
  ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive
  =drive-ide0-0-0,id=ide0-0-0 -drive file=/home/damarion/iso/virtio-
  win-0.1-74.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw
  -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
  -netdev tap,fd=24,id=hostnet0 -device
  e1000,netdev=hostnet0,id=net0,mac=52:54:00:38:31:0a,bus=pci.0,addr=0x3
  -chardev pty,id=charserial0 -device isa-
  serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0
  -vnc 127.0.0.1:1 -device VGA,id=video0,bus=pci.0,addr=0x2 -device
  virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions

[Qemu-devel] [Bug 1308341] Re: Multiple CPUs causes blue screen on Windows guest (14.04 regression)

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: virt-manager (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1308341

Title:
  Multiple CPUs causes blue screen on Windows guest (14.04 regression)

Status in QEMU:
  New
Status in “qemu” package in Ubuntu:
  Confirmed
Status in “virt-manager” package in Ubuntu:
  Confirmed

Bug description:
  Configuring a Windows 7 guest using more than one CPU cases the guest to 
fail. This happens after a few hours after guest boot. This is the error on the 
blue screen:
  A clock interrupt was not received on a secondary processor within the 
allocated time interval

  After resetting, the guest will never boot and a new bluescreen with
  the error STOP: 0x005c appears. Shutting down the guest
  completely and restarting it will allow it to boot and run for a few
  hours again.

  The guest was created using virt-manager. The error happens with or
  without virtio devices and with both 32-bit and 64-bit Windows 7
  guests.

  I am using Ubuntu 14.04 release candidate.

  qemu-kvm version 2.0.0~rc1+dfsg-0ubuntu3

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1308341/+subscriptions

[Qemu-devel] [Bug 1322302] [NEW] local provider is very slow to tranistion from agent-status: pending

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

ubuntu@trusty-installer:~$ juju version
1.18.3-trusty-amd64
ubuntu@trusty-installer:~$ dpkg -l juju-core
ii  juju-core1.18.3-0ubuntu1~1 amd64 Juju is devops 
distilled - client
ubuntu@trusty-installer:~$ dpkg -l juju-local
ii  juju-local   1.18.3-0ubuntu1~1 all   dependency 
package for the Juju local provider

juju add-machine --constraints mem=3G cpu-cores=3 root-disk=20G
has a huge delay in agent-state pending especially when the kvm is up and 
running in fairly short order

kvm comes up in ~1 minutes, agent-status is stuck in pending for at
least another 8-9 minutes after that

hazmat danwest, its normally async to actually coming up based on
pinger/heartbeat.. but that length of time sounds like a worst case..

** Affects: qemu
 Importance: High
 Assignee: Canonical Server Team (canonical-server)
 Status: Incomplete


** Tags: cloud-installer
-- 
local provider is very slow to tranistion from agent-status: pending 
https://bugs.launchpad.net/bugs/1322302
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 1243287] Re: [KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail

[Launchpad Bug Tracker]

** Branch linked: lp:cloud-init

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287

Title:
  [KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail

Status in QEMU:
  Confirmed

Bug description:
  On booting the cloud image using qemu/kvm fails with the following
  error:

  Cloud-init v. 0.7.3 running 'init' at Thu, 03 Oct 2013 16:45:21 +. Up 
360.78 seconds.
  ci-info: +Net device info+
  ci-info: ++--+---+---+---+
  ci-info: | Device | Up | Address | Mask | Hw-Address |
  ci-info: ++--+---+---+---+
  ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . |
  ci-info: | eth0 | True | 10.0.2.15 | 255.255.255.0 | 52:54:00:12:34:56 |
  ci-info: ++--+---+---+---+
  ci-info: ++Route 
info++
  ci-info: 
+---+-+--+---+---+---+
  ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
  ci-info: 
+---+-+--+---+---+---+
  ci-info: | 0 | 0.0.0.0 | 10.0.2.2 | 0.0.0.0 | eth0 | UG |
  ci-info: | 1 | 10.0.2.0 | 0.0.0.0 | 255.255.255.0 | eth0 | U |
  ci-info: 
+---+-+--+---+---+---+
  error: kvm run failed Function not implemented

  /usr/lib/python2.7/dist-
  packages/cloudinit/sources/DataSourceAltCloud.py assumes that
  dmidecode command is availabe (ie it assumes that system is x86) on
  arm systems there is no dmidecode command so host kvm fails with the
  message error: kvm run failed Function not implemented

  The patch makes get_cloud_type() function return with UNKNOWN for ARM
  systems.

  I was able to boot the cloud-image on ARM after applying this change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1243287/+subscriptions

[Qemu-devel] [Bug 1243287] Re: [KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/cloud-init

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287

Title:
  [KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail

Status in QEMU:
  Fix Committed

Bug description:
  On booting the cloud image using qemu/kvm fails with the following
  error:

  Cloud-init v. 0.7.3 running 'init' at Thu, 03 Oct 2013 16:45:21 +. Up 
360.78 seconds.
  ci-info: +Net device info+
  ci-info: ++--+---+---+---+
  ci-info: | Device | Up | Address | Mask | Hw-Address |
  ci-info: ++--+---+---+---+
  ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . |
  ci-info: | eth0 | True | 10.0.2.15 | 255.255.255.0 | 52:54:00:12:34:56 |
  ci-info: ++--+---+---+---+
  ci-info: ++Route 
info++
  ci-info: 
+---+-+--+---+---+---+
  ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags |
  ci-info: 
+---+-+--+---+---+---+
  ci-info: | 0 | 0.0.0.0 | 10.0.2.2 | 0.0.0.0 | eth0 | UG |
  ci-info: | 1 | 10.0.2.0 | 0.0.0.0 | 255.255.255.0 | eth0 | U |
  ci-info: 
+---+-+--+---+---+---+
  error: kvm run failed Function not implemented

  /usr/lib/python2.7/dist-
  packages/cloudinit/sources/DataSourceAltCloud.py assumes that
  dmidecode command is availabe (ie it assumes that system is x86) on
  arm systems there is no dmidecode command so host kvm fails with the
  message error: kvm run failed Function not implemented

  The patch makes get_cloud_type() function return with UNKNOWN for ARM
  systems.

  I was able to boot the cloud-image on ARM after applying this change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1243287/+subscriptions

[Qemu-devel] [Bug 1285363] Re: qemu-aarch64-static segfaults

[Launchpad Bug Tracker]

** Branch linked: lp:ubuntu/trusty-proposed/qemu

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1285363

Title:
  qemu-aarch64-static segfaults

Status in QEMU:
  New
Status in “qemu” package in Ubuntu:
  Confirmed

Bug description:
  I've found a couple conditions that causes qemu-user-static to core
  dump fairly reliably - same with upstream git - while a binary built
  from suse's aarch64-1.6 branch seems to consistently work fine.

  Testing suggests they are resolved by the sigprocmask wrapper patches
  included in suse's tree.

   1) dh_fixperms is a script that commonly runs at the end of a package build.
   Its basically doing a `find | xargs chmod`.
   2) debootstrap --second-stage
   This is used to configure an arm64 chroot that was built using
   debootstrap on a non-native host. It is basically invoking a bunch of
   shell scripts (postinst, etc). When it blows up, the stack consistently
   looks like this:

  Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
  /debootstrap/debootstrap --second-stage'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
  __dest=0x400082c330) at
  /usr/include/x86_64-linux-gnu/bits/string3.h:51
  51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
  (gdb) bt
  #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
  __dest=0x400082c330) at
  /usr/include/x86_64-linux-gnu/bits/string3.h:51
  #1  stq_p (v=274886476624, ptr=0x400082c330) at
  /mnt/qemu.upstream/include/qemu/bswap.h:280
  #2  stq_le_p (v=274886476624, ptr=0x400082c330) at
  /mnt/qemu.upstream/include/qemu/bswap.h:315
  #3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
  sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
  #4  target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
  sigact_table+512, info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
  env=env@entry=0x62d9c678)
  at /mnt/qemu.upstream/linux-user/signal.c:1286
  #5  0x60059f46 in setup_frame (env=0x62d9c678,
  set=0x7fff62ae3530, ka=0x604ec1e0 sigact_table+512, sig=17) at
  /mnt/qemu.upstream/linux-user/signal.c:1322
  #6  process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at
  /mnt/qemu.upstream/linux-user/signal.c:5747
  #7  0x60056e60 in cpu_loop (env=env@entry=0x62d9c678) at
  /mnt/qemu.upstream/linux-user/main.c:1082
  #8  0x60005079 in main (argc=optimized out, argv=optimized
  out, envp=optimized out) at
  /mnt/qemu.upstream/linux-user/main.c:4374

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285363/+subscriptions

[Qemu-devel] [Bug 1285363] Re: qemu-aarch64-static segfaults

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 1.7.0+dfsg-3ubuntu5

---
qemu (1.7.0+dfsg-3ubuntu5) trusty; urgency=medium

  [ dann frazier ]
  * Add patches from the susematz tree to avoid intermittent segfaults:
 - ubuntu/signal-added-a-wrapper-for-sigprocmask-function.patch
 - ubuntu/signal-sigsegv-protection-on-do_sigprocmask.patch
 - ubuntu/Don-t-block-SIGSEGV-at-more-places.patch

  [ Serge Hallyn ]
  * Modify do_sigprocmask to only change behavior for aarch64.
(LP: #1285363)
 -- Serge Hallyn serge.hal...@ubuntu.com   Thu, 06 Mar 2014 16:15:50 -0600

** Changed in: qemu (Ubuntu)
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1285363

Title:
  qemu-aarch64-static segfaults

Status in QEMU:
  New
Status in “qemu” package in Ubuntu:
  Fix Released

Bug description:
  I've found a couple conditions that causes qemu-user-static to core
  dump fairly reliably - same with upstream git - while a binary built
  from suse's aarch64-1.6 branch seems to consistently work fine.

  Testing suggests they are resolved by the sigprocmask wrapper patches
  included in suse's tree.

   1) dh_fixperms is a script that commonly runs at the end of a package build.
   Its basically doing a `find | xargs chmod`.
   2) debootstrap --second-stage
   This is used to configure an arm64 chroot that was built using
   debootstrap on a non-native host. It is basically invoking a bunch of
   shell scripts (postinst, etc). When it blows up, the stack consistently
   looks like this:

  Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
  /debootstrap/debootstrap --second-stage'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
  __dest=0x400082c330) at
  /usr/include/x86_64-linux-gnu/bits/string3.h:51
  51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
  (gdb) bt
  #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
  __dest=0x400082c330) at
  /usr/include/x86_64-linux-gnu/bits/string3.h:51
  #1  stq_p (v=274886476624, ptr=0x400082c330) at
  /mnt/qemu.upstream/include/qemu/bswap.h:280
  #2  stq_le_p (v=274886476624, ptr=0x400082c330) at
  /mnt/qemu.upstream/include/qemu/bswap.h:315
  #3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
  sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
  #4  target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
  sigact_table+512, info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
  env=env@entry=0x62d9c678)
  at /mnt/qemu.upstream/linux-user/signal.c:1286
  #5  0x60059f46 in setup_frame (env=0x62d9c678,
  set=0x7fff62ae3530, ka=0x604ec1e0 sigact_table+512, sig=17) at
  /mnt/qemu.upstream/linux-user/signal.c:1322
  #6  process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at
  /mnt/qemu.upstream/linux-user/signal.c:5747
  #7  0x60056e60 in cpu_loop (env=env@entry=0x62d9c678) at
  /mnt/qemu.upstream/linux-user/main.c:1082
  #8  0x60005079 in main (argc=optimized out, argv=optimized
  out, envp=optimized out) at
  /mnt/qemu.upstream/linux-user/main.c:4374

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285363/+subscriptions

[Qemu-devel] [Bug 1368815] Re: qemu-img convert intermittently corrupts output images

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: qemu (Ubuntu Vivid)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815

Title:
  qemu-img convert intermittently corrupts output images

Status in OpenStack Compute (Nova):
  In Progress
Status in QEMU:
  In Progress
Status in “qemu” package in Ubuntu:
  Confirmed
Status in “qemu” source package in Trusty:
  Triaged
Status in “qemu” source package in Utopic:
  Triaged
Status in “qemu” source package in Vivid:
  Confirmed

Bug description:
  -- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on
  Ubuntu 14.04 using Ext4 filesystems.

  The command

qemu-img convert -O raw inputimage.qcow2 outputimage.raw

  intermittently creates corrupted output images, when the input image
  is not yet fully synchronized to disk. While the issue has actually
  been discovered in operation of of OpenStack nova, it can be
  reproduced easily on command line using

cat $SRC_PATH  $TMP_PATH  $QEMU_IMG_PATH convert -O raw $TMP_PATH
  $DST_PATH  cksum $DST_PATH

  on filesystems exposing this behavior. (The difficult part of this
  exercise is to prepare a filesystem to reliably trigger this race. On
  my test machine some filesystems are affected while other aren't, and
  unfortunately I haven't found the relevant difference between them,
  yet. Possible it's timing issues completely out of userspace control
  ...)

  The root cause, however, is the same as in

http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html

  and it can be solved the same way as suggested in

http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html

  In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change

  f.fm.fm_flags = 0;

  to

  f.fm.fm_flags = FIEMAP_FLAG_SYNC;

  As discussed in the thread mentioned above, retrieving a page cache
  coherent map of file extents is possible only after fsync on that
  file.

  See also

https://bugs.launchpad.net/nova/+bug/1350766

  In that bug report filed against nova, fsync had been suggested to be
  performed by the framework invoking qemu-img. However, as the choice
  of fiemap -- implying this otherwise unneeded fsync of a temporary
  file  -- is not made by the caller but by qemu-img, I agree with the
  nova bug reviewer's objection to put it into nova. The fsync should
  instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC,
  specifically intended for that purpose.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368815/+subscriptions

[Qemu-devel] [Bug 1368815] Re: qemu-img convert intermittently corrupts output images

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.1+dfsg-4ubuntu7

---
qemu (2.1+dfsg-4ubuntu7) vivid; urgency=medium

  * Apply two patches to fix intermittent qemu-img corruption
(LP: #1368815)
- 501-block-raw-posix-fix-disk-corruption-in-try-fiemap
- 502-block-raw-posic-use-seek-hole-ahead-of-fiemap
 -- Serge Hallyn serge.hal...@ubuntu.com   Wed, 29 Oct 2014 22:31:43 -0500

** Changed in: qemu (Ubuntu Vivid)
   Status: Confirmed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815

Title:
  qemu-img convert intermittently corrupts output images

Status in OpenStack Compute (Nova):
  In Progress
Status in QEMU:
  In Progress
Status in “qemu” package in Ubuntu:
  Fix Released
Status in “qemu” source package in Trusty:
  Triaged
Status in “qemu” source package in Utopic:
  Triaged
Status in “qemu” source package in Vivid:
  Fix Released

Bug description:
  -- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on
  Ubuntu 14.04 using Ext4 filesystems.

  The command

qemu-img convert -O raw inputimage.qcow2 outputimage.raw

  intermittently creates corrupted output images, when the input image
  is not yet fully synchronized to disk. While the issue has actually
  been discovered in operation of of OpenStack nova, it can be
  reproduced easily on command line using

cat $SRC_PATH  $TMP_PATH  $QEMU_IMG_PATH convert -O raw $TMP_PATH
  $DST_PATH  cksum $DST_PATH

  on filesystems exposing this behavior. (The difficult part of this
  exercise is to prepare a filesystem to reliably trigger this race. On
  my test machine some filesystems are affected while other aren't, and
  unfortunately I haven't found the relevant difference between them,
  yet. Possible it's timing issues completely out of userspace control
  ...)

  The root cause, however, is the same as in

http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html

  and it can be solved the same way as suggested in

http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html

  In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change

  f.fm.fm_flags = 0;

  to

  f.fm.fm_flags = FIEMAP_FLAG_SYNC;

  As discussed in the thread mentioned above, retrieving a page cache
  coherent map of file extents is possible only after fsync on that
  file.

  See also

https://bugs.launchpad.net/nova/+bug/1350766

  In that bug report filed against nova, fsync had been suggested to be
  performed by the framework invoking qemu-img. However, as the choice
  of fiemap -- implying this otherwise unneeded fsync of a temporary
  file  -- is not made by the caller but by qemu-img, I agree with the
  nova bug reviewer's objection to put it into nova. The fsync should
  instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC,
  specifically intended for that purpose.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368815/+subscriptions

[Qemu-devel] [Bug 1349277] Re: AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.1+dfsg-7ubuntu3

---
qemu (2.1+dfsg-7ubuntu3) vivid; urgency=medium

  * d/p/target-arm-A64-Break-out-aarch64_save-restore_sp.patch
d/p/target-arm-A64-Respect-SPSEL-in-ERET-SP-restore.patch
d/p/target-arm-A64-Respect-SPSEL-when-taking-exceptions.patch:
Cherry-pick of upstream patches in order to fix AArch64 emulation ignoring
SPSel=0 in certain conditions. (LP: #1349277)
 -- Chris J Arges chris.j.ar...@canonical.com   Thu, 04 Dec 2014 14:17:01 
-0600

** Changed in: qemu (Ubuntu)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1349277

Title:
  AArch64 emulation ignores SPSel=0 when taking (or returning from) an
  exception at EL1 or greater

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Released

Bug description:
  The AArch64 emulation ignores SPSel=0 when:

  (1) taking an interrupt from an exception level greater than EL0
  (e.g., EL1t),

  (2) returning from an exception (via ERET) to an exception level
  greater than EL0 (e.g., EL1t), with SPSR_ELx[SPSel]=0.

  The attached patch fixes the problem in my application.

  Background:

  I'm running a standalone application (toy OS) that is performing
  preemptive multithreading between threads running at EL1t, with
  exception handling / context switching occurring at EL1h.  This bug
  causes the stack pointer to be corrupted in the threads running at
  EL1t (they end up with a version of the EL1h stack pointer (SP_EL1)).

  Occurs in:
qemu-2.1.0-rc1 (found in)
commit c60a57ff497667780132a3fcdc1500c83af5d5c0 (current master)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1349277/+subscriptions

[Qemu-devel] [Bug 1368815] Re: qemu-img convert intermittently corrupts output images

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.8

---
qemu (2.0.0+dfsg-2ubuntu1.8) trusty-proposed; urgency=medium

  * debian/qemu-system-x86.qemu-kvm.upstart: create /dev/kvm in a
container. (LP: #1370199)
  * Cherrypick upstream patch to fix intermittent qemu-img corruption
(LP: #1368815)
- 501-block-raw-posix-fix-disk-corruption-in-try-fiemap
- (note - 502-block-raw-posic-use-seek-hole-ahead-of-fiemap (which was
  also needed in utopic) appears to be unneeded here as the code being
  changed has not yet been switched to using try_fiemap)
 -- Serge Hallyn serge.hal...@ubuntu.com   Thu, 20 Nov 2014 11:24:51 -0600

** Changed in: qemu (Ubuntu Trusty)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815

Title:
  qemu-img convert intermittently corrupts output images

Status in OpenStack Compute (Nova):
  In Progress
Status in QEMU:
  In Progress
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Fix Released
Status in qemu source package in Utopic:
  Fix Committed
Status in qemu source package in Vivid:
  Fix Released

Bug description:
  ==
  Impact: occasional image corruption (any format on local filesystem)
  Test case: see the qemu-img command below
  Regression potential: this cherrypicks a patch from upstream to a 
not-insignificantly older qemu source tree.  While the cherrypick seems sane, 
it's possible that there are subtle interactions with the other delta.  I'd 
really like for a full qa-regression-test qemu testcase to be run against this 
package.
  ==

  -- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on
  Ubuntu 14.04 using Ext4 filesystems.

  The command

    qemu-img convert -O raw inputimage.qcow2 outputimage.raw

  intermittently creates corrupted output images, when the input image
  is not yet fully synchronized to disk. While the issue has actually
  been discovered in operation of of OpenStack nova, it can be
  reproduced easily on command line using

    cat $SRC_PATH  $TMP_PATH  $QEMU_IMG_PATH convert -O raw $TMP_PATH
  $DST_PATH  cksum $DST_PATH

  on filesystems exposing this behavior. (The difficult part of this
  exercise is to prepare a filesystem to reliably trigger this race. On
  my test machine some filesystems are affected while other aren't, and
  unfortunately I haven't found the relevant difference between them,
  yet. Possible it's timing issues completely out of userspace control
  ...)

  The root cause, however, is the same as in

    http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html

  and it can be solved the same way as suggested in

    http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html

  In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change

  f.fm.fm_flags = 0;

  to

  f.fm.fm_flags = FIEMAP_FLAG_SYNC;

  As discussed in the thread mentioned above, retrieving a page cache
  coherent map of file extents is possible only after fsync on that
  file.

  See also

    https://bugs.launchpad.net/nova/+bug/1350766

  In that bug report filed against nova, fsync had been suggested to be
  performed by the framework invoking qemu-img. However, as the choice
  of fiemap -- implying this otherwise unneeded fsync of a temporary
  file  -- is not made by the caller but by qemu-img, I agree with the
  nova bug reviewer's objection to put it into nova. The fsync should
  instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC,
  specifically intended for that purpose.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368815/+subscriptions

[Qemu-devel] [Bug 1368815] Re: qemu-img convert intermittently corrupts output images

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.1+dfsg-4ubuntu6.2

---
qemu (2.1+dfsg-4ubuntu6.2) utopic-proposed; urgency=medium

  * Apply two patches to fix intermittent qemu-img corruption
(LP: #1368815)
- 501-block-raw-posix-fix-disk-corruption-in-try-fiemap
- 502-block-raw-posic-use-seek-hole-ahead-of-fiemap
 -- Serge Hallyn serge.hal...@ubuntu.com   Thu, 20 Nov 2014 16:33:09 -0600

** Changed in: qemu (Ubuntu Utopic)
   Status: Fix Committed = Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815

Title:
  qemu-img convert intermittently corrupts output images

Status in OpenStack Compute (Nova):
  In Progress
Status in QEMU:
  In Progress
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Fix Released
Status in qemu source package in Utopic:
  Fix Released
Status in qemu source package in Vivid:
  Fix Released

Bug description:
  ==
  Impact: occasional image corruption (any format on local filesystem)
  Test case: see the qemu-img command below
  Regression potential: this cherrypicks a patch from upstream to a 
not-insignificantly older qemu source tree.  While the cherrypick seems sane, 
it's possible that there are subtle interactions with the other delta.  I'd 
really like for a full qa-regression-test qemu testcase to be run against this 
package.
  ==

  -- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on
  Ubuntu 14.04 using Ext4 filesystems.

  The command

    qemu-img convert -O raw inputimage.qcow2 outputimage.raw

  intermittently creates corrupted output images, when the input image
  is not yet fully synchronized to disk. While the issue has actually
  been discovered in operation of of OpenStack nova, it can be
  reproduced easily on command line using

    cat $SRC_PATH  $TMP_PATH  $QEMU_IMG_PATH convert -O raw $TMP_PATH
  $DST_PATH  cksum $DST_PATH

  on filesystems exposing this behavior. (The difficult part of this
  exercise is to prepare a filesystem to reliably trigger this race. On
  my test machine some filesystems are affected while other aren't, and
  unfortunately I haven't found the relevant difference between them,
  yet. Possible it's timing issues completely out of userspace control
  ...)

  The root cause, however, is the same as in

    http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html

  and it can be solved the same way as suggested in

    http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html

  In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change

  f.fm.fm_flags = 0;

  to

  f.fm.fm_flags = FIEMAP_FLAG_SYNC;

  As discussed in the thread mentioned above, retrieving a page cache
  coherent map of file extents is possible only after fsync on that
  file.

  See also

    https://bugs.launchpad.net/nova/+bug/1350766

  In that bug report filed against nova, fsync had been suggested to be
  performed by the framework invoking qemu-img. However, as the choice
  of fiemap -- implying this otherwise unneeded fsync of a temporary
  file  -- is not made by the caller but by qemu-img, I agree with the
  nova bug reviewer's objection to put it into nova. The fsync should
  instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC,
  specifically intended for that purpose.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368815/+subscriptions

[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: glusterfs (Ubuntu Trusty)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297218

Title:
  guest hangs after live migration due to tsc jump

Status in QEMU:
  New
Status in glusterfs package in Ubuntu:
  Invalid
Status in qemu package in Ubuntu:
  Triaged
Status in glusterfs source package in Trusty:
  Confirmed
Status in qemu source package in Trusty:
  Confirmed

Bug description:
  We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing
  a Gluster filesystem. Guests can be live migrated between them.
  However, live migration often leads to the guest being stuck at 100%
  for a while. In that case, the dmesg output for such a guest will show
  (once it recovers): Clocksource tsc unstable (delta = 662463064082
  ns). In this particular example, a guest was migrated and only after
  11 minutes (662 seconds) did it become responsive again.

  It seems that newly booted guests doe not suffer from this problem,
  these can be migrated back and forth at will. After a day or so, the
  problem becomes apparent. It also seems that migrating from server A
  to server B causes much more problems than going from B back to A. If
  necessary, I can do more measurements to qualify these observations.

  The VM servers run Ubuntu 13.04 with these packages:
  Kernel: 3.8.0-35-generic x86_64
  Libvirt: 1.0.2
  Qemu: 1.4.0
  Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using 
libgfapi yet as the Ubuntu libvirt is not linked against libgfapi).
  The interconnect between both machines (both for migration and gluster) is 
10GbE. 
  Both servers are synced to NTP and well within 1ms form one another.

  Guests are either Ubuntu 13.04 or 13.10.

  On the guests, the current_clocksource is kvm-clock.
  The XML definition of the guests only contains:  clock offset='utc'/ 

  Now as far as I've read in the documentation of kvm-clock, it specifically 
supports live migrations, so I'm a bit surprised at these problems. There isn't 
all that much information to find on these issue, although I have found 
postings by others that seem to have run into the same issues, but without a 
solution.
  --- 
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: libvirt (not installed)
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic 
root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 
BOOTIF=01-00-25-90-75-b5-c8
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Tags:  trusty apparmor apparmor apparmor apparmor apparmor
  Uname: Linux 3.13.0-24-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  modified.conffile..etc.default.libvirt.bin: [modified]
  modified.conffile..etc.libvirt.libvirtd.conf: [modified]
  modified.conffile..etc.libvirt.qemu.conf: [modified]
  modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted]
  mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662
  mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837
  mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions

[Qemu-devel] [Bug 1294898] Re: gtk: menubar visible in fullscreen mode with gtk3

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: ubuntu-gnome3-desktop (Ubuntu)
   Status: New = Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1294898

Title:
  gtk: menubar visible in fullscreen mode with gtk3

Status in QEMU:
  New
Status in ubuntu-gnome3-desktop package in Ubuntu:
  Confirmed

Bug description:
  Using the gtk UI, compiled with gtk3, the menu bar is fully visible in
  full screen mode. On gtk2 it's hidden. The set_size_request call isn't
  abided on gtk3 it seems.

  Simple fix is:

  diff --git a/ui/gtk.c b/ui/gtk.c
  index 66e886f..7b3bd3d 100644
  --- a/ui/gtk.c
  +++ b/ui/gtk.c
  @@ -805,7 +805,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void 
*opaque)
   
   if (!s-full_screen) {
   gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s-notebook), FALSE);
  -gtk_widget_set_size_request(s-menu_bar, 0, 0);
  +gtk_widget_hide(s-menu_bar);
   gtk_widget_set_size_request(s-drawing_area, -1, -1);
   gtk_window_fullscreen(GTK_WINDOW(s-window));
   if (gd_on_vga(s)) {
  @@ -815,7 +815,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void 
*opaque)
   } else {
   gtk_window_unfullscreen(GTK_WINDOW(s-window));
   gd_menu_show_tabs(GTK_MENU_ITEM(s-show_tabs_item), s);
  -gtk_widget_set_size_request(s-menu_bar, -1, -1);
  +gtk_widget_show(s-menu_bar);
   gtk_widget_set_size_request(s-drawing_area,
   surface_width(s-ds),
   surface_height(s-ds));

  
  The problem with that is that hiding the menu bar means all its associated 
accelerators are no longer usable, so there's way to exit fullscreen mode. 
That's kind of a problem :)

  We can install the accelerators on the window, but make sure the menu
  item still shows the accelerator short cut. Example with the
  fullscreen accelerator:

  diff --git a/ui/gtk.c b/ui/gtk.c
  index 66e886f..fbce2b0 100644
  --- a/ui/gtk.c
  +++ b/ui/gtk.c
  @@ -799,7 +799,7 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void 
*opaque)
   }
   }
   
  -static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
  +static void gd_do_full_screen(void *opaque)
   {
   GtkDisplayState *s = opaque;
   
  @@ -828,6 +828,11 @@ static void gd_menu_full_screen(GtkMenuItem *item, void 
*opaque)
   gd_update_cursor(s, FALSE);
   }
   
  +static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
  +{
  +gd_do_full_screen(opaque);
  +}
  +
   static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque)
   {
   GtkDisplayState *s = opaque;
  @@ -1304,10 +1309,11 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState 
*s, GtkAccelGroup *accel_g
   gtk_menu_set_accel_group(GTK_MENU(view_menu), accel_group);
   
   s-full_screen_item = gtk_menu_item_new_with_mnemonic(_(_Fullscreen));
  -gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s-full_screen_item),
  - QEMU/View/Full Screen);
  -gtk_accel_map_add_entry(QEMU/View/Full Screen, GDK_KEY_f,
  -HOTKEY_MODIFIERS);
  +gtk_accel_group_connect(accel_group, GDK_KEY_f, HOTKEY_MODIFIERS, 0,
  + g_cclosure_new_swap(G_CALLBACK(gd_do_full_screen), s, NULL));
  +gtk_accel_label_set_accel(
  +GTK_ACCEL_LABEL(gtk_bin_get_child(GTK_BIN(s-full_screen_item))),
  +GDK_KEY_f, HOTKEY_MODIFIERS);
   gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s-full_screen_item);
   
   separator = gtk_separator_menu_item_new();

  
  However gtk_accel_label_set_accel, which shows the accel key sequence in the 
menu, is gtk 3.8+ :/ So older versions wouldn't have any visual indication of 
the shortcuts. Maybe that's not a problem, SDL didn't have any indication of 
shortcuts either.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1294898/+subscriptions

[Qemu-devel] [Bug 1465935] Re: kvm_irqchip_commit_routes: Assertion `ret == 0' failed

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 1:2.3+dfsg-5ubuntu9

---
qemu (1:2.3+dfsg-5ubuntu9) wily; urgency=low

  * debian/patches/upstream-fix-irq-route-entries.patch
Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed"
(LP: #1465935)

 -- Stefan Bader   Fri, 09 Oct 2015 15:38:53
+0200

** Changed in: qemu (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1465935

Title:
  kvm_irqchip_commit_routes: Assertion `ret == 0' failed

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Precise:
  New
Status in qemu source package in Trusty:
  New
Status in qemu source package in Utopic:
  Won't Fix
Status in qemu source package in Vivid:
  New

Bug description:
  Several my QEMU instances crashed, and in the  qemu log, I can see
  this assertion failure,

 qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/kvm-all.c:984:
  kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

  The QEMU version is 2.0.0, HV OS is ubuntu 12.04, kernel 3.2.0-38.
  Guest OS is RHEL 6.3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1465935/+subscriptions

[Qemu-devel] [Bug 1422307] Re: qemu-nbd corrupts files

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.18

---
qemu (2.0.0+dfsg-2ubuntu1.18) trusty-proposed; urgency=medium

  * qemu-nbd-fix-vdi-corruption.patch:
qemu-nbd: fix corruption while writing VDI volumes (LP: #1422307)

 -- Pierre Schweitzer   Mon, 17 Aug 2015 11:43:39
+0200

** Changed in: qemu (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1422307

Title:
  qemu-nbd corrupts files

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Fix Released

Bug description:
  [Impact]
  A race condition in the VDI block driver of Qemu leads to image (and thus 
file system) corruption under certain circumstances.
  This makes Qemu tools usage for VDI formatted images particularly dangerous 
(qemu-img, qemu-nbd).
  The bug fix introduces locks to prevent such race condition.

  
  [Test Case]
  A simple test case was provided in comment #5 
(https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1422307/comments/5):

  $ ./qemu-img create -f vdi test.vdi 2G
  Formatting 'test.vdi', fmt=vdi size=2147483648 static=off
  $ ./qemu-img create -f raw test.raw 2G
  Formatting 'test.raw', fmt=raw size=2147483648
  $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -drive 
if=virtio,file=blkverify:test.raw:test.vdi,format=raw -drive 
if=virtio,file=data.img,format=raw,format=raw -cdrom ~/tmp/arch.iso -m 512 
-boot d
  blkverify: read sector_num=810976 nb_sectors=256 contents mismatch in sector 
811008

  Operations in the guest:
  $ dd if=/dev/vdb of=/dev/vda
  $ dd if=/dev/vda of=/dev/null

  [Regression Potential]
  In case of bugs affecting the way locks are used, deadlocks could be a 
regression, but they would only affect VDI images.

  
  Original bug report:
  Dear all,

  On Trusty, in certain situations, try to copy files over a qemu-nbd
  mounted file system leads to write errors (and thus, file corruption).

  Here is the last example I tried:
  -> virtual disk is a VDI disk
  -> It has only one partition, in FAT

  Here is my mount process:
  # modprobe nbd max_part=63
  # qemu-nbd -c /dev/nbd0 "virtual_disk.vdi"
  # partprobe /dev/nbd0
  # mount /dev/nbd0p1 /tmp/mnt/

  Partition is properly mounted at that point:
  /dev/nbd0p1 on /tmp/mnt type vfat (rw)

  Now, when I copy a file (rather big, ~28MB):
  # cp file_to_copy /tmp/mnt/ ; sync
  # md5sum /tmp/mnt/file_to_copy
  2efc9f32e4267782b11d63d2f128a363  /tmp/mnt/file_to_copy
  # umount /tmp/mnt
  # mount /dev/nbd0p1 /tmp/mnt/
  # md5sum /tmp/mnt/file_to_copy
  42b0a3bf73f704d03ce301716d7654de  /tmp/mnt/file_to_copy

  The first hash was obviously the right one.

  On a previous attempt I did, I spotted thanks to vbindiff that parts of the 
file were just filed with 0s instead of actual data.
  It will randomly work after several attempts to write.

  Version information:
  # qemu-nbd --version
  qemu-nbd version 0.0.1
  Written by Anthony Liguori.

  Cheers,

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1422307/+subscriptions

[Qemu-devel] [Bug 1006655] Re: Can't convert to vmdk with the streamOptimized subformat

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 1:2.3+dfsg-5ubuntu6

---
qemu (1:2.3+dfsg-5ubuntu6) wily; urgency=medium

  * Make qemu-system-common and qemu-utils depend on qemu-block-extra
to fix errors with missing block backends. (LP: #1495895)
  * Cherry pick fixes for vmdk stream-optimized subformat (LP: #1006655)
  * Apply fix for memory corruption during live-migration in tcg mode
(LP: #1493049)
  * Apply tracing patch to remove use of custom vtable in newer glibc
(LP: #1491972)

 -- Ryan Harper   Tue, 15 Sep 2015 09:37:23
-0500

** Changed in: qemu (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1006655

Title:
  Can't convert to vmdk with the streamOptimized subformat

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu-kvm package in Ubuntu:
  Confirmed

Bug description:
  Hi all,
  I'm trying to convert a qcow2 image file to the vmdk (on Ubuntu Server 12.04):

  # qemu-img convert -f qcow2 -O vmdk -o Stream spv-2912.qcow2 spv-2912-3.vmdk 
-o subformat=streamOptimized
  VMDK: can't write to allocated cluster for streamOptimized
  qemu-img: error while writing sector 65: Input/output error

  Same result with any input format. Others subformats work but the
  StreamOptimized is by far the most important one. The only workaround
  I found is to migrate to raw and then to use VBoxManage (VirtualBox).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1006655/+subscriptions

[Qemu-devel] [Bug 1465935] Re: kvm_irqchip_commit_routes: Assertion `ret == 0' failed

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 1:2.2+dfsg-5expubuntu9.6

---
qemu (1:2.2+dfsg-5expubuntu9.6) vivid; urgency=low

  * debian/patches/upstream-fix-irq-route-entries.patch
Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed"
(LP: #1465935)

 -- Stefan Bader   Fri, 09 Oct 2015 17:04:26
+0200

** Changed in: qemu (Ubuntu Vivid)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1465935

Title:
  kvm_irqchip_commit_routes: Assertion `ret == 0' failed

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Fix Released
Status in qemu source package in Utopic:
  Won't Fix
Status in qemu source package in Vivid:
  Fix Released

Bug description:
  Several my QEMU instances crashed, and in the  qemu log, I can see
  this assertion failure,

 qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/kvm-all.c:984:
  kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

  The QEMU version is 2.0.0, HV OS is ubuntu 12.04, kernel 3.2.0-38.
  Guest OS is RHEL 6.3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1465935/+subscriptions

[Qemu-devel] [Bug 1465935] Re: kvm_irqchip_commit_routes: Assertion `ret == 0' failed

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.20

---
qemu (2.0.0+dfsg-2ubuntu1.20) trusty; urgency=low

  * debian/patches/upstream-fix-irq-route-entries.patch
Fix "kvm_irqchip_commit_routes: Assertion 'ret == 0' failed"
(LP: #1465935)

 -- Stefan Bader   Fri, 09 Oct 2015 17:16:30
+0200

** Changed in: qemu (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1465935

Title:
  kvm_irqchip_commit_routes: Assertion `ret == 0' failed

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Fix Released
Status in qemu source package in Utopic:
  Won't Fix
Status in qemu source package in Vivid:
  Fix Released

Bug description:
  Several my QEMU instances crashed, and in the  qemu log, I can see
  this assertion failure,

 qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/kvm-all.c:984:
  kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

  The QEMU version is 2.0.0, HV OS is ubuntu 12.04, kernel 3.2.0-38.
  Guest OS is RHEL 6.3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1465935/+subscriptions

[Qemu-devel] [Bug 1583775] [NEW] Feature Request: qemu 2.6.0

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Qemu 2.6.0 just got released, and according to changelogs it has quite
some enhancements...

would it be possible to have someone who has a qemu ppa on launchpad to
migrate this into his ppa?

thanks in advance

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: kvm qemu spice vfio virtio
-- 
Feature Request: qemu 2.6.0
https://bugs.launchpad.net/bugs/1583775
You received this bug notification because you are a member of qemu-devel-ml, 
which is subscribed to QEMU.

[Qemu-devel] [Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: ubuntu
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794

Title:
  9pfs does not honor open file handles on unlinked files

Status in QEMU:
  New
Status in Ubuntu:
  Confirmed

Bug description:
  This was originally filed over here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1114221

  The open-unlink-fstat idiom used in some places to create an anonymous
  private temporary file does not work in a QEMU guest over a virtio-9p
  filesystem.

  Version-Release number of selected component (if applicable):

  qemu-kvm-1.6.2-6.fc20.x86_64
  qemu-system-x86-1.6.2-6.fc20.x86_64
  (those are fedora RPMs)

  How reproducible:

  Always. See this example C program:

  https://bugzilla.redhat.com/attachment.cgi?id=913069

  Steps to Reproduce:
  1. Export a filesystem with virt-manager for the guest.
(type: mount, driver: default, mode: passthrough)
  2. Start guest and mount that filesystem
(mount -t 9p -o trans=virtio,version=9p2000.L  ...)
  3. Run a program that uses open-unlink-fstat
(in my case it was trying to compile Perl 5.20)

  Actual results:

  fstat fails:

  open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
  unlink("/home/tst/filename")= 0
  fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or 
directory)
  close(3)

  Expected results:

  open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
  unlink("/home/tst/filename")= 0
  fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
  fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
  close(3) 

  Additional info:

  There was a patch put into the kernel back in '07 to handle this very
  problem for other filesystems; maybe its helpful:

http://lwn.net/Articles/251228/

  There is also a thread on LKML from last December specifically about
  this very problem:

https://lkml.org/lkml/2013/12/31/163

  There was a discussion on the QEMU list back in '11 that doesn't seem
  to have come to a conclusion, but did provide the test program that
  i've attached to this report:

http://marc.info/?l=qemu-devel=130443605720648=2

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions

[Qemu-devel] [Bug 1455475] Re: Block Commit: [100 %]error: failed to pivot job for disk vda

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: ubuntu
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1455475

Title:
  Block Commit: [100 %]error: failed to pivot job for disk vda

Status in QEMU:
  New
Status in Ubuntu:
  Confirmed

Bug description:
  Hi,

  i´ve a Problem with committing a snapshot. The problem was discussed
  on the libvirt mailing list earlier this year.

  https://www.redhat.com/archives/libvirt-
  users/2015-January/msg00029.html

  
  Iam running gentoo and:

  Compiled against library: libvirt 1.2.14
  Using library: libvirt 1.2.14
  Using API: QEMU 1.2.14
  Running hypervisor: QEMU 2.3.0

  I´am running a Windows Server 2012 R2 VM with the latest quest driver
  (0.1.96) and  QEMU quest Agent 0.12.1 installed.

  The domain is started with following command line:

  /usr/bin/qemu-system-x86_64 -name $DOMAIN -S -machine 
pc-i440fx-1.6,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 
8,sockets=8,cores=1,threads=1 -uuid c96ef576-dbfc-49aa-9dd0-068886c4ef0e 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/$DOMAIN.monitor,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime 
-no-shutdown -boot strict=on -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive 
file=/var/lib/libvirt/images/$DOMAIN.qcow2,if=none,id=drive-virtio-disk0,format=qcow2
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:07:b4:0a,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev 
socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait 
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 -device usb-tablet,id=input0 -vnc 127.0.0.1:6 -k de -device 
VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on
  char device redirected to /dev/pts/2 (label charserial0)

  
  I´ve created the snapshot with:

  virsh # snapshot-create-as --domain $DOMAIN snap1 --diskspec 
vda,file=/var/lib/libvirt/images/snap1.qcow2 --quiesce --disk-only --atomic 
--no-metadata
  Domain snapshot snap1 created

  If i try to commit the snapshot i get this error:

  virsh # blockcommit $DOMAIN vda --active --verbose --pivot
  error: internal error: unable to execute QEMU command 'block-commit': Device 
'drive-virtio-disk0' is busy: block device is in use by block job: commit

  
  virsh # blockjob $DOMAIN /var/lib/libvirt/images/snap1.qcow2
  Block Commit: [100 %]

  virsh # $DOMAIN var/lib/libvirt/images/snap1.qcow2 --abort

  virsh # blockjob $DOMAIN /var/lib/libvirt/images/snap1.qcow2
  No current block job for /var/lib/libvirt/images/snap1.qcow2

  
  I´ve test this with qemu 2.1 and the problem does`nt exist.

  /usr/bin/qemu-system-x86_64 -name $DOMAIN -S -machine pc-
  i440fx-1.6,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp
  8,sockets=8,cores=1,threads=1 -uuid 30c49f37-6e62-49f6-a9df-
  ad2fef1fa312 -no-user-config -nodefaults -chardev
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/$DOMAIN.monitor,server,nowait
  -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
  -no-shutdown -boot strict=on -device piix3-usb-
  uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id
  =virtio-serial0,bus=pci.0,addr=0x6 -drive
  file=/var/lib/libvirt/images/$DOMAIN.qcow2,if=none,id=drive-virtio-
  disk0,format=qcow2 -device virtio-blk-
  pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-
  disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-
  serial,chardev=charserial0,id=serial0 -chardev
  
socket,id=charchannel0,path=/var/lib/libvirt/qemu/f16x86_64.agent,server,nowait
  -device virtserialport,bus=virtio-
  serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
  -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k de -device
  VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 -device virtio-balloon-
  pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on


  Compiled against library: libvirt 1.2.11
  Using library: libvirt 1.2.11
  Using API: QEMU 1.2.11
  Running hypervisor: QEMU 2.1.2

  
  virsh # snapshot-create-as --domain windows.trohde-snapshot-test 
windows.trohde-snapshot-test_snap1 --diskspec 
vda,file=/var/lib/libvirt/images/windows.trohde-snapshot-test_snap1.qcow2 
--quiesce --disk-only --atomic --no-metadata
  Domain snapshot windows.trohde-snapshot-test_snap1 created

  virsh # blockcommit $DOMAIN vda --active --verbose --pivot
  Block Commit: [100 %]
  Successfully pivoted

  Cheers

  Tim

[Qemu-devel] [Bug 1297218] Re: guest hangs after live migration due to tsc jump

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.25

---
qemu (2.0.0+dfsg-2ubuntu1.25) trusty; urgency=medium

  [Kai Storbeck]
  * backport patch to fix guest hangs after live migration (LP: #1297218)

 -- Serge Hallyn   Fri, 01 Jul 2016 14:25:20
-0500

** Changed in: qemu (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1297218

Title:
  guest hangs after live migration due to tsc jump

Status in QEMU:
  New
Status in glusterfs package in Ubuntu:
  Invalid
Status in qemu package in Ubuntu:
  Fix Released
Status in glusterfs source package in Trusty:
  Confirmed
Status in qemu source package in Trusty:
  Fix Released

Bug description:
  =
  SRU Justification:
  1. Impact: guests hang after live migration with 100% cpu
  2. Upstream fix: a set of four patches fix this upstream
  3. Stable fix: we have a backport of the four patches into a single patch.
  4. Test case: try a set of migrations of different VMS (it is unfortunately 
not 100% reproducible)
  5. Regression potential: the patch is not trivial, however the 
lp:qa-regression-tests testsuite passed 100% with this package.
  =

  We have two identical Ubuntu servers running libvirt/kvm/qemu, sharing
  a Gluster filesystem. Guests can be live migrated between them.
  However, live migration often leads to the guest being stuck at 100%
  for a while. In that case, the dmesg output for such a guest will show
  (once it recovers): Clocksource tsc unstable (delta = 662463064082
  ns). In this particular example, a guest was migrated and only after
  11 minutes (662 seconds) did it become responsive again.

  It seems that newly booted guests doe not suffer from this problem,
  these can be migrated back and forth at will. After a day or so, the
  problem becomes apparent. It also seems that migrating from server A
  to server B causes much more problems than going from B back to A. If
  necessary, I can do more measurements to qualify these observations.

  The VM servers run Ubuntu 13.04 with these packages:
  Kernel: 3.8.0-35-generic x86_64
  Libvirt: 1.0.2
  Qemu: 1.4.0
  Gluster-fs: 3.4.2 (libvirt access the images via the filesystem, not using 
libgfapi yet as the Ubuntu libvirt is not linked against libgfapi).
  The interconnect between both machines (both for migration and gluster) is 
10GbE.
  Both servers are synced to NTP and well within 1ms form one another.

  Guests are either Ubuntu 13.04 or 13.10.

  On the guests, the current_clocksource is kvm-clock.
  The XML definition of the guests only contains:  

  Now as far as I've read in the documentation of kvm-clock, it specifically 
supports live migrations, so I'm a bit surprised at these problems. There isn't 
all that much information to find on these issue, although I have found 
postings by others that seem to have run into the same issues, but without a 
solution.
  ---
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: libvirt (not installed)
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic 
root=UUID=1b0c3c6d-a9b8-4e84-b076-117ae267d178 ro console=ttyS1,115200n8 
BOOTIF=01-00-25-90-75-b5-c8
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Tags:  trusty apparmor apparmor apparmor apparmor apparmor
  Uname: Linux 3.13.0-24-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

  _MarkForUpload: True
  modified.conffile..etc.default.libvirt.bin: [modified]
  modified.conffile..etc.libvirt.libvirtd.conf: [modified]
  modified.conffile..etc.libvirt.qemu.conf: [modified]
  modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted]
  mtime.conffile..etc.default.libvirt.bin: 2014-05-12T19:07:40.020662
  mtime.conffile..etc.libvirt.libvirtd.conf: 2014-05-13T14:40:25.894837
  mtime.conffile..etc.libvirt.qemu.conf: 2014-05-12T18:58:27.885506

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1297218/+subscriptions

[Qemu-devel] [Bug 1490611] Re: Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: qemu (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1490611

Title:
  Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to
  the result file, which Microsoft Azure rejects as invalid

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Confirmed
Status in qemu source package in Xenial:
  New

Bug description:
  Starting with a raw disk image, using "qemu-img convert" to convert
  from raw to VHD results in the output VHD file's virtual size being
  aligned to the nearest 516096 bytes (16 heads x 63 sectors per head x
  512 bytes per sector), instead of preserving the input file's size as
  the output VHD's virtual disk size.

  Microsoft Azure requires that disk images (VHDs) submitted for upload
  have virtual sizes aligned to a megabyte boundary. (Ex. 4096MB,
  4097MB, 4098MB, etc. are OK, 4096.5MB is rejected with an error.) This
  is reflected in Microsoft's documentation: https://azure.microsoft.com
  /en-us/documentation/articles/virtual-machines-linux-create-upload-
  vhd-generic/

  This is reproducible with the following set of commands (including the
  Azure command line tools from https://github.com/Azure/azure-xplat-
  cli). For the following example, I used qemu version 2.2.1:

  $ dd if=/dev/zero of=source-disk.img bs=1M count=4096

  $ stat source-disk.img 
File: ‘source-disk.img’
Size: 4294967296  Blocks: 798656 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247963Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:48:02.613988480 -0700
  Modify: 2015-08-18 09:48:02.825985646 -0700
  Change: 2015-08-18 09:48:02.825985646 -0700
   Birth: -

  $ qemu-img convert -f raw -o subformat=fixed -O vpc source-disk.img
  dest-disk.vhd

  $ stat dest-disk.vhd 
File: ‘dest-disk.vhd’
Size: 4296499712  Blocks: 535216 IO Block: 4096   regular file
  Device: fc01h/64513dInode: 13247964Links: 1
  Access: (0644/-rw-r--r--)  Uid: ( 1000/  smkent)   Gid: ( 1000/  smkent)
  Access: 2015-08-18 09:50:22.252077624 -0700
  Modify: 2015-08-18 09:49:24.424868868 -0700
  Change: 2015-08-18 09:49:24.424868868 -0700
   Birth: -

  $ azure vm image create testimage1 dest-disk.vhd -o linux -l "West US"
  info:Executing command vm image create
  + Retrieving storage accounts 
 
  info:VHD size : 4097 MB
  info:Uploading 4195800.5 KB
  Requested:100.0% Completed:100.0% Running:   0 Time: 1m 0s Speed:  6744 KB/s 
  info:https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd was 
uploaded successfully
  error:   The VHD 
https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd has an 
unsupported virtual size of 4296499200 bytes.  The size must be a whole number 
(in MBs).
  info:Error information has been recorded to /home/smkent/.azure/azure.err
  error:   vm image create command failed

  I also ran the above commands using qemu 2.4.0, which resulted in the
  same error as the conversion behavior is the same.

  However, qemu 2.1.1 and earlier (including qemu 2.0.0 installed by
  Ubuntu 14.04) does not pad the virtual disk size during conversion.
  Using qemu-img convert from qemu versions <=2.1.1 results in a VHD
  that is exactly the size of the raw input file plus 512 bytes (for the
  VHD footer). Those qemu versions do not attempt to realign the disk.
  As a result, Azure accepts VHD files created using those versions of
  qemu-img convert for upload.

  Is there a reason why newer qemu realigns the converted VHD file? It
  would be useful if an option were added to disable this feature, as
  current versions of qemu cannot be used to create VHD files for Azure
  using Microsoft's official instructions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1490611/+subscriptions

[Qemu-devel] [Bug 613529] Re: qemu does not accept regular disk geometry

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/613529

Title:
  qemu does not accept regular disk geometry

Status in QEMU:
  Expired

Bug description:
  Hi,

  I am currently hunting a strange bug in qemu/kvm:

  I am using an lvm logical volume as a virtual hard disk for a virtual
  machine.

  I use fdisk or parted to create a partition table and partitions,
  kpartx to generate the device entries for the partitions, then install
  linux on ext3/ext4 with grub or msdos filesystem with syslinux.

  But then, in most cases even the boot process fails or behaves
  strangely, sometimes even mounting the file system in the virtual
  machine fails. It seems as if there is a problem with the virtual disk
  geometry. The problem does not seem to occur if I reboot the host
  system after creating the partition table on the logical volume. I
  guess the linux kernel needs to learn the disk geometry by reboot. A
  blkdev --rereadpt does not work on lvm volumes.

  The first approach to test/fix the problem would be to pass the disk
  geometry to qemu/lvm with the -drive option. Unfortunately, qemu/kvm
  does not accept the default geometry with 255 heads and 63 sectors.
  Seems to limit the number of heads to 16, thus limiting the disk size.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/613529/+subscriptions

[Qemu-devel] [Bug 920772] Re: Win98SE glitches RHEL6.2/CentOS6.2 QEMU

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/920772

Title:
  Win98SE glitches RHEL6.2/CentOS6.2 QEMU

Status in QEMU:
  Expired

Bug description:
  I'm not sure if this is something anyone will be interested in,
  but I ran into some glitches setting up a Windows 98 SE
  QEMU VM with a relatively recent version.  Needed this
  to restore an ancient backup and got it working well
  enough to get the job done.

  Versions
  

  Distro: CentOS 6.2

  Kernel: upstream 3.1.8

  QEMU:
  gpxe-roms-qemu-0.9.7-6.9.el6.noarch
  qemu-img-0.12.1.2-2.209.el6_2.1.x86_64
  qemu-kvm-0.12.1.2-2.209.el6_2.1.x86_64

  Glitches:

  1) Doesn't work in KVM mode, screen goes black
  just after installer is finishing up and switching to
  Win98.  Saw this issue has been around for awhile.

  2) Got it working in QEMU mode, but BIOS plug-n-play
  driver fails.  This prevents other devices from working.

  a) CDROM not recognized

  b) Realtek 8139C driver (installed separately after
  Win98) not recognized.

  I don't need these issues fixed, just reporting the
  in case it's of interest and/or helpful.  Can provide
  more detail on request.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/920772/+subscriptions

[Qemu-devel] [Bug 1248469] Re: qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1248469

Title:
  qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit

Status in QEMU:
  Expired

Bug description:
  boot windows 7 32bit guest with -readconfig q35-chipset.cfg
  paramter,in guest's device manager,there's a device 3420 not work,it
  shows error "This device cannot find enough free resources that it can
  use(code 12)".

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1248469/+subscriptions

[Qemu-devel] [Bug 1221966] Re: SIGSEGV in static_code_gen_buffer

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1221966

Title:
  SIGSEGV in static_code_gen_buffer

Status in QEMU:
  Expired

Bug description:
  Trying to run 'ls' (or, anything else as far as I can tell) from a
  SunOS 5.8 box under RHEL 6.4 linux, I get a segfault.  I've tried
  qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-
  project.org/qemu.git.  I've also tried a statically linked sh from
  /sbin/ and it also segfaulted.

  wcolburn@anotheruvula$ gdb bin/qemu-sparc
  GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
  Copyright (C) 2010 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-redhat-linux-gnu".
  For bug reporting instructions, please see:
  ...
  Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done.
  (gdb) run ../sparc/ls
  Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls
  [Thread debugging using libthread_db enabled]

  Program received signal SIGSEGV, Segmentation fault.
  0x78259116 in static_code_gen_buffer ()
  Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 
glibc-2.12-1.107.el6_4.4.x86_64
  (gdb) where
  #0  0x78259116 in static_code_gen_buffer ()
  #1  0x77f570cd in cpu_tb_exec (cpu=0x7a2b1210, tb_ptr=
  0x782590d0 "A\213n \205í\017\205Í")
  at /home/anotheruvula/qemu-devel/cpu-exec.c:56
  #2  0x77f57b2d in cpu_sparc_exec (env=0x7a2b1348)
  at /home/anotheruvula/qemu-devel/cpu-exec.c:631
  #3  0x77f77f36 in cpu_loop (env=0x7a2b1348)
  at /home/anotheruvula/qemu-devel/linux-user/main.c:1089
  #4  0x77f798ff in main (argc=2, argv=0x7fffdfc8, envp=
  0x7fffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083
  (gdb)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1221966/+subscriptions

[Qemu-devel] [Bug 1243639] Re: qemu-1.5.3 segment fault with -vga qxl

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243639

Title:
  qemu-1.5.3   segment fault  with  -vga qxl

Status in QEMU:
  Expired

Bug description:
  execute " qemu-system-x86_64-enable-kvm -machine accel=kvm:tcg -m
  1G  -drive file=/dev/sda  --full-screen -spice
  addr=127.0.0.1,port=5900,disable-ticketing -vga qxl "  on shell will
  get  segment fault  after  a few seconds   if  I  don't connect to it
  with  spicec client  immediately.

  IF  excute  "spicec -h 127.0.0.1 -p 5900 "  immediately after
  the  qemu-system-x86_64  execution, then  no segment fault happens
  and  it runs well.

  =

  GDB output:

  root@kali-john:~# gdb /usr/local/bin/qemu-system-x86_64
  GNU gdb (GDB) 7.4.1-debian
  (gdb) run -enable-kvm -machine accel=kvm:tcg -m 1G  -drive file=/dev/sda  
--full-screen -spice addr=127.0.0.1,port=5900,disable-ticketing -vga qxl

  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [New Thread 0x73737700 (LWP 14797)]
  [New Thread 0x72d54700 (LWP 14798)]
  [New Thread 0x70fff700 (LWP 14799)]

  Program received signal SIGSEGV, Segmentation fault.
  0x7683ad70 in pixman_image_get_data () from 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0
  (gdb) bt
  #0  0x7683ad70 in pixman_image_get_data () from 
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0
  #1  0x5581060a in surface_data (s=0x566183a0) at 
/zh-download/QEMU/qemu-1.5.3/include/ui/console.h:235
  #2  0x55818616 in vga_draw_graphic (s=0x5662c778, full_update=1) 
at /zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1788
  #3  0x55818c6a in vga_update_display (opaque=0x5662c778) at 
/zh-download/QEMU/qemu-1.5.3/hw/display/vga.c:1917
  #4  0x5580eb15 in qxl_hw_update (opaque=0x5662bd70) at 
/zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1766
  #5  0x557bd6bc in graphic_hw_update (con=0x56618d00) at 
ui/console.c:254
  #6  0x557c8426 in qemu_spice_display_refresh (ssd=0x5662c418) at 
ui/spice-display.c:417
  #7  0x5580eff0 in display_refresh (dcl=0x5662c420) at 
/zh-download/QEMU/qemu-1.5.3/hw/display/qxl.c:1886
  #8  0x557c0cb1 in dpy_refresh (s=0x56618370) at ui/console.c:1436
  #9  0x557bd3af in gui_update (opaque=0x56618370) at 
ui/console.c:192
  #10 0x55797f20 in qemu_run_timers (clock=0x565b5a30) at 
qemu-timer.c:394
  #11 0x55798183 in qemu_run_all_timers () at qemu-timer.c:453
  #12 0x55760bb7 in main_loop_wait (nonblocking=0) at main-loop.c:470
  #13 0x557cd19c in main_loop () at vl.c:2029
  #14 0x557d43f2 in main (argc=13, argv=0x7fffe2b8, 
envp=0x7fffe328) at vl.c:4419
  (gdb) 

  
  ==

  http://www.spice-space.org/download/releases/spice-0.12.4.tar.bz2
  http://www.spice-space.org/download/releases/spice-protocol-0.12.6.tar.bz2
  spice  compiling 
./configure --enable-smartcard=no   && make

  qemu-1.5.3
  compiling 
  ./configure \
  --disable-strip  --enable-debug \
  --target-list=x86_64-softmmu,x86_64-linux-user  \
  --disable-sdl  --audio-drv-list=alsa --disable-vnc --disable-xen 
--disable-libiscsi  \
--disable-seccomp --disable-glusterfs --disable-libssh2 
--disable-smartcard-nss  \
--disable-usb-redir --disable-brlapi --disable-curl  --disable-bsd-user 
\
\
  --enable-kvm --enable-spice --enable-system --enable-guest-agent 
--enable-vhost-net 

  
  root@kali-john:~# qemu-system-x86_64 -version
  QEMU emulator version 1.5.3, Copyright (c) 2003-2008 Fabrice Bellard

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1243639/+subscriptions

[Qemu-devel] [Bug 1646610] Re: "Assertion `!r->req.sg' failed." during live migration with VirtIO

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1646610

Title:
  "Assertion `!r->req.sg' failed." during live migration with VirtIO

Status in QEMU:
  Expired

Bug description:
  We've hit this issue twice so far, but don't have an obvious repro
  yet. It's pretty rare for us to hit it but I'm still trying so I can
  get a core and backtrace. The guest was Windows running a constant
  workload. We were using VirtIO SCSI drivers in both cases.

  In both cases we hit the assert here:

  hw/scsi/scsi-generic.c:

  static void scsi_generic_save_request(QEMUFile *f, SCSIRequest *req)
  {
  SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req);

  qemu_put_sbe32s(f, >buflen);
  if (r->buflen && r->req.cmd.mode == SCSI_XFER_TO_DEV) {
  *** assert(!r->req.sg);
  qemu_put_buffer(f, r->buf, r->req.cmd.xfer);
  }
  }

  From code inspection, it seems that this will always happen if
  scsi_req_enqueue_internal in hw/scsi/scsi-bus.c is ever invoked.

  static void scsi_req_enqueue_internal(SCSIRequest *req)
  {
  assert(!req->enqueued);
  scsi_req_ref(req);
  if (req->bus->info->get_sg_list) {
  req->sg = req->bus->info->get_sg_list(req);
  } else {
  req->sg = NULL;
  }
  req->enqueued = true;
  QTAILQ_INSERT_TAIL(>dev->requests, req, next);
  }

  req->bus->info->get_sg_list will return >qsgl for a virtio-scsi
  bus since it's a method stored on the SCSIBusInfo struct. I didn't see
  anything that would clear the req->sg if scsi_req_enqueue_internal is
  called at least once.

  I think this can only happen if scsi_dma_restart_bh in hw/scsi/scsi-
  bus.c is called. The only other location I see
  scsi_req_enqueue_internal is on the load side for the destination of a
  migration.

  static void scsi_dma_restart_bh(void *opaque)
  {
  SCSIDevice *s = opaque;
  SCSIRequest *req, *next;

  qemu_bh_delete(s->bh);
  s->bh = NULL;

  QTAILQ_FOREACH_SAFE(req, >requests, next, next) {
  scsi_req_ref(req);
  if (req->retry) {
  req->retry = false;
  switch (req->cmd.mode) {
  case SCSI_XFER_FROM_DEV:
  case SCSI_XFER_TO_DEV:
  scsi_req_continue(req);
  break;
  case SCSI_XFER_NONE:
  scsi_req_dequeue(req);
  scsi_req_enqueue(req); // *** this calls 
scsi_req_enqueue_internal
  break;
  }
  }
  scsi_req_unref(req);
  }
  }

  Finally when put_scsi_requests is called for migration, it seems like
  it will call both virtio_scsi_save_request (from
  bus->info->save_request) and scsi_generic_save_request (from
  req->ops->save_request) and trigger the assert.

  I searched for a bit, but didn't find anyone else reporting this. Has
  anyone else seen this? It seems to me like that assert should check
  that the sg list is empty instead of checking that it exists. Is this
  an appropriate assessment? Assuming I find a repro, I'll try to test
  this solution.

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1646610/+subscriptions

[Qemu-devel] [Bug 498417] Re: cache=writeback on disk image doesn't do write-back

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/498417

Title:
  cache=writeback on disk image doesn't do write-back

Status in QEMU:
  Expired

Bug description:
  I noticed that qemu seems to have poor disk performance.  Here's a
  test that has miserable performance but which should be really fast:

  - Configure qemu to use the disk image with cache=writeback
  - Configure a 2GiB Linux VM on an 8GiB Linux host
  - In the VM, write a 4GiB file (dd if=/dev/zero of=/tmp/x bs=4K count=1M)
  - In the VM, read it back (dd if=/tmp/x of=/dev/null bs=4K count=1M)

  With writeback, the whole file should end up in the host pagecache.
  So when I read it back, there should be no I/O to the real disk, and
  it should be really fast.  Instead, I see disk activity through the
  duration of the test, and the performance is roughly the native hard
  disk throughput (somewhat slower).

  I'm using version 0.11.1, and this is my command line:

  qemu-system-x86_64 -drive
  cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048
  -smp 2 -vnc :3100 -usbdevice tablet -enable-kvm &

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/498417/+subscriptions

[Qemu-devel] [Bug 584516] Re: opensuse 11.2 guest hangs after live migration with clocksource=kvm-clock

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/584516

Title:
  opensuse 11.2 guest hangs after live migration with clocksource=kvm-
  clock

Status in QEMU:
  Expired

Bug description:
  i would like to debug a problem that I encountered some time ago with 
opensuse 11.2 and also
  with Ubuntu (karmic/lucid).

  If I run an opensuse guest 64-bit and do not touch the clocksource settings 
the guest almost
  everytime hangs after live migration at:

  (gdb) thread apply all bt

  Thread 2 (Thread 0x7f846782a950 (LWP 27356)):
  #0  0x7f8467d24cd7 in ioctl () from /lib/libc.so.6
  #1  0x0042b945 in kvm_run (env=0x2468170)
at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921
  #2  0x0042cea2 in kvm_cpu_exec (env=0x2468170)
at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651
  #3  0x0042d62c in kvm_main_loop_cpu (env=0x2468170)
at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893
  #4  0x0042d76d in ap_main_loop (_env=0x2468170)
at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943
  #5  0x7f8468caa3ba in start_thread () from /lib/libpthread.so.0
  #6  0x7f8467d2cfcd in clone () from /lib/libc.so.6
  #7  0x in ?? ()

  Thread 1 (Thread 0x7f84692d96f0 (LWP 27353)):
  #0  0x7f8467d25742 in select () from /lib/libc.so.6
  #1  0x0040c25a in main_loop_wait (timeout=1000)
at /usr/src/qemu-kvm-0.12.4/vl.c:3994
  #2  0x0042dcf1 in kvm_main_loop ()
at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126
  #3  0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212
  #4  0x0041054b in main (argc=31, argv=0x7fffa91351c8,
envp=0x7fffa91352c8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252

  If I run the same guest with kernel parameter clocksource=acpi_pm, the
  migration succeeds reliably.

  The hosts runs:
  /kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3

  I invoke qemu-kvm with:
  /usr/bin/qemu-kvm-0.12.4  -net none  -drive 
file=/dev/sdb,if=ide,boot=on,cache=none,aio=native  -m 1024 -cpu 
qemu64,model_id='Intel(R) Xeon(R) CPU   E5430  @ 2.66GHz'  -monitor 
tcp:0:4001,server,nowait -vnc :1 -name 'test'  -boot order=dc,menu=on  -k de  
-pidfile /var/run/qemu/vm-149.pid  -mem-path /hugepages -mem-prealloc  -rtc 
base=utc,clock=vm -usb -usbdevice tablet

  The Guest is:
  OpenSuse 11.2 64-bit with Kernel 2.6.31.5-0.1-desktop #1 SMP PREEMPT 
2009-10-26 15:49:03 +0100 x86_64
  The clocksource automatically choosen is kvm-clock.

  Feedback appreciated. I have observed the same problem with 0.12.2 and
  also with old binaries provided by Ubuntu Karmic (kvm-88).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/584516/+subscriptions

[Qemu-devel] [Bug 1163065] Re: target-i386 cpu_get_phys_page_debug checks bits in wrong order

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1163065

Title:
  target-i386 cpu_get_phys_page_debug checks bits in wrong order

Status in QEMU:
  Expired

Bug description:
  In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked
  before CR0_PG. This means that if paging is disabled but the PAE bit
  has been set in CR4, cpu_get_phys_page_debug will return the wrong
  result (it will try to translate the address as virtual rather than
  using it as a physical address).

  Although this might seem like an unusual case, it in fact happens
  consistently when booting Linux on amd64 (from
  linux-2.6.32.60/arch/x86/boot/compressed/head_64.S):

  /* Enable PAE mode */
  xorl%eax, %eax
  orl $(X86_CR4_PAE), %eax
  movl%eax, %cr4
  [... code to set up page tables omitted ...]
  /* Enter paged protected Mode, activating Long Mode */
  movl$(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected 
mode */
  movl%eax, %cr0

  The most noticeable effect of this bug is that using the disassembler
  during this time will fetch the wrong data by trying to read from page
  tables that aren't there. One symptom is that booting Linux amd64 with
  -d in_asm will result in several "Disassembler disagrees with
  translator over instruction decoding" messages.

  Attached is a patch that moves the CR0_PG check to the beginning. I'm
  still not 100% certain that the logic of cpu_get_phys_page_debug
  matches cpu_x86_handle_mmu_fault, but it's a start.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1163065/+subscriptions

[Qemu-devel] [Bug 1186935] Re: [1.5] QEMU monitor gets overlapped by GTK menu bar

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1186935

Title:
  [1.5] QEMU monitor gets overlapped by GTK menu bar

Status in QEMU:
  Expired

Bug description:
  The QEMU minitor gets partially hidden by the menu bar which was
  introduced in QEMU version 1.5.0.

  Steps to reproduce:

   1. Run `qemu-system-x86_64`
   2. Press Ctrl + Alt + 2 (or use the menu bar)
   3. Observe that the monitor output is partially shown, without the 
"compat_monitor0 console" and "QEMU 1.5.0 monitor - type 'help' for more 
information" lines.

  Attached is a screenshot of `qemu-system-x86_64` and `qemu-system-
  x86_64 -display sdl`.

  Version: 1.5.0
  Distribution: Arch Linux 64-bit

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1186935/+subscriptions

[Qemu-devel] [Bug 1027525] Re: Unable to insert cd media located on ro nfs mount

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1027525

Title:
  Unable to insert cd media located on ro nfs mount

Status in QEMU:
  Expired

Bug description:
  When issuing a "change" command via the monitor, qemu is unable to
  open the iso file if it is mounted on a read-only nfs share. If I
  mount read-write (and make sure the file is writable by the qemu
  process), then the change command succeeds. Note that this doesn't
  affect media specified on the command line when starting qemu, only
  when changing via the monitor.

  To reproduce, mount cd images directory read only, e.g.

  [root@kvmhost0 ~]# grep iso /etc/fstab
  10.48.50.20:/iso /srv/kvm/iso nfs4 defaults,ro 0 0

  Start qemu with minimal options, just need access to the monitor:

  [root@kvmhost0 ~]# kvm -vnc 127.0.0.1:0 -S

  Connect to the monitor and issue a change command:

  (qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso
  Could not open '/srv/kvm/iso/ubuntu-12.04-server-amd64.iso

  Re-mount the iso directory read-write and notice that the command
  succeeds:

  [root@kvmhost0 ~]# mount -o remount,rw /srv/kvm/iso

  (qemu) change ide1-cd0 /srv/kvm/iso/ubuntu-12.04-server-amd64.iso
  (qemu)

  [root@kvmhost0 ~]# kvm --version
  QEMU emulator version 1.1.1 (qemu-kvm-1.1.1), Copyright (c) 2003-2008 Fabrice 
Bellard
  [root@kvmhost0 ~]# uname -a
  Linux kvmhost0 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 
x86_64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1027525/+subscriptions

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

[Launchpad Bug Tracker]

This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.7

---
qemu (1:2.5+dfsg-5ubuntu10.7) xenial; urgency=medium

  [ Rafael David Tinoco ]
  * Fixed wrong migration blocker when vhost is used (LP: #1626972)
- d/p/vhost_migration-blocker-only-if-shared-log-is-used.patch

 -- Christian Ehrhardt   Tue, 22 Nov
2016 13:45:39 +0100

** Changed in: qemu (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1626972

Title:
  QEMU memfd_create fallback mechanism change for security drivers

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Fix Released
Status in qemu source package in Yakkety:
  Fix Released
Status in qemu source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * Updated QEMU (from UCA) live migration doesn't work with 3.13 kernels.
   * QEMU code checks if it can create /tmp/memfd-XXX files wrongly.
   * Apparmor will block access to /tmp/ and QEMU will fail migrating.

  [Test Case]

   * Install 2 Ubuntu Trusty (3.13) + UCA Mitaka + apparmor rules.
   * Try to live-migration from one to another. 
   * Apparmor will block creation of /tmp/memfd-XXX files.

  [Regression Potential]

   Pros:
   * Exhaustively tested this.
   * Worked with upstream on this fix. 
   * I'm implementing new vhost log mechanism for upstream.
   * One line change to a blocker that is already broken.

   Cons:
   * To break live migration in other circumstances. 

  [Other Info]

   * Christian Ehrhardt has been following this.

  ORIGINAL DESCRIPTION:

  When libvirt starts using apparmor, and creating apparmor profiles for
  every virtual machine created in the compute nodes, mitaka qemu (2.5 -
  and upstream also) uses a fallback mechanism for creating shared
  memory for live-migrations. This fall back mechanism, on kernels 3.13
  - that don't have memfd_create() system-call, try to create files on
  /tmp/ directory and fails.. causing live-migration not to work.

  Trusty with kernel 3.13 + Mitaka with qemu 2.5 + apparmor capability =
  can't live migrate.

  From qemu 2.5, logic is on :

  void *qemu_memfd_alloc(const char *name, size_t size, unsigned int seals, int 
*fd)
  {
  if (memfd_create)... ### only works with HWE kernels

  else ### 3.13 kernels, gets blocked by apparmor
     tmpdir = g_get_tmp_dir
     ...
     mfd = mkstemp(fname)
  }

  And you can see the errors:

  From the host trying to send the virtual machine:

  2016-08-15 16:36:26.160 1974 ERROR nova.virt.libvirt.driver 
[req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 
133ebc3585c041aebaead8c062cd6511 - - -] [instance: 
2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Migration operation has aborted
  2016-08-15 16:36:26.248 1974 ERROR nova.virt.libvirt.driver 
[req-0cac612b-8d53-4610-b773-d07ad6bacb91 691a581cfa7046278380ce82b1c38ddd 
133ebc3585c041aebaead8c062cd6511 - - -] [instance: 
2afa1131-bc8c-43d2-9c4a-962c1bf7723e] Live Migration failure: internal error: 
unable to execute QEMU command 'migrate': Migration disabled: failed to 
allocate shared memory

  From the host trying to receive the virtual machine:

  Aug 15 16:36:19 tkcompute01 kernel: [ 1194.356794] type=1400 
audit(1471289779.791:72): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" 
pid=12565 comm="apparmor_parser"
  Aug 15 16:36:19 tkcompute01 kernel: [ 1194.357048] type=1400 
audit(1471289779.791:73): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="qemu_bridge_helper" pid=12565 comm="apparmor_parser"
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.877027] type=1400 
audit(1471289780.311:74): apparmor="STATUS" operation="profile_replace" 
profile="unconfined" name="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" 
pid=12613 comm="apparmor_parser"
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.904407] type=1400 
audit(1471289780.343:75): apparmor="STATUS" operation="profile_replace" 
profile="unconfined" name="qemu_bridge_helper" pid=12613 comm="apparmor_parser"
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.973064] type=1400 
audit(1471289780.407:76): apparmor="DENIED" operation="mknod" 
profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/memfd-tNpKSj" 
pid=12625 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 
ouid=107
  Aug 15 16:36:20 tkcompute01 kernel: [ 1194.979871] type=1400 
audit(1471289780.411:77): apparmor="DENIED" operation="open" 
profile="libvirt-2afa1131-bc8c-43d2-9c4a-962c1bf7723e" name="/tmp/" pid=12625 
comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
  Aug 15 16:36:20 tkcompute01 

[Qemu-devel] [Bug 744856] Re: can't boot when using more than 6 disks since qemu-kvm-0.13

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/744856

Title:
  can't boot when using more than 6 disks since qemu-kvm-0.13

Status in QEMU:
  Expired

Bug description:
  It's not possible to pass more than 6 disks to a guest since qemu-kvm-0.13 
(also tested with 0.14).
  If I pass more than 6 disks (as shown below) the machine complains that their 
is no bootable disk,

  The problem occurs with virtio and without virtio.

  eg.

  /usr/bin/qemu-system-x86_64  --enable-kvm -boot c   -drive
  file=/dev/vgr5/fs-01,if=virtio -drive file=/dev/vgr5/fs-
  01_srv_workspace,if=virtio -drive file=/dev/vgr5/fs-
  01_srv_media,if=virtio -drive file=/dev/vgr5/fs-
  01_srv_company,if=virtio -drive file=/dev/vgr5/fs-01_srv_tmp,if=virtio
  -drive file=/dev/vgr5/fs-01_srv_download,if=virtio -drive
  file=/dev/vgr5/fs-01_srv_share,if=virtio -drive file=/dev/vgr5/fs-
  01_srv_backup,if=virtio -drive file=/dev/vgr5/fs-
  01_srv_private,if=virtio -drive file=/dev/vgr5/fs-
  01_srv_build,if=virtio -drive file=/dev/vgr5/fs-01_srv_dev,if=virtio
  -drive file=/dev/vgr5/fs-01_srv_backup2,if=virtio -drive
  file=/dev/vgr5/fs-01_srv_ftp,if=virtio  -cpu qemu64 -smp 2  -m 4G
  -append root=/dev/vda -usbdevice tablet -net
  nic,macaddr=90:e6:ba:9d:00:0,model=e1000 -net
  tap,ifname=tap0,script=/usr/sbin/qemu-ifup,downscript=/usr/sbin/qemu-
  ifdown  -monitor unix:/var/run/kvm/fs-01/monitor,server,nowait
  -pidfile /var/run/kvm/fs-01/pid  -k de -kernel
  /srv/kvm/kernel/linux-2.6.38-gentoo -append root=/dev/vda -vnc :0
  -name fs-01,process=fs-01 -vga std

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/744856/+subscriptions

[Qemu-devel] [Bug 1484925] Re: Segfault with custom vnc client

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1484925

Title:
  Segfault with custom vnc client

Status in QEMU:
  Expired

Bug description:
  Hey,

  I'm using Citrix XenServer 6.5. I worte a script that uses noVNC to
  connect to the rfb console via xapi. When I use GRML and try to boot
  it, the QEMU process segfaults and kills my VM. This happens when the
  screen resizes and the kernel is loading:

  recvfrom(3, "\3\1\0\0\0\0\2\200\1\220\3\0\2\200\0\0\0P\1\220", 4096, 0, NULL, 
NULL) = 20
  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb28000} ---

  I can see in the child process the following message, right before the parent 
Segfaults:
  read(4, "cirrus: blanking the screen line_offset=0 height=480\n", 53) = 53

  This issue only happens, when I have my custom php/novnc-client
  connected. I also tried the nodejs/novnc package from xen-orchestra -
  same result. Using the stock client from Citrix XenCenter it works
  just fine. So I think it is related to noVNC. I hope this is just a
  bug and not exploitable to force a VM to crash or execute code.

  XenServer launches the qemu with the following command line:

  qemu-dm-25 --syslog -d 25 -m 2048 -boot dc -serial pty -vcpus 1
  -videoram 4 -vncunused -k en-us -vnc 127.0.0.1:1 -usb -usbdevice
  tablet -net nic,vlan=0,macaddr=8a:43:e2:b1:57:df,model=rtl8139 -net
  tap,vlan=0,bridge=xenbr0,ifname=tap25.0 -acpi -monitor pty

  XenServer 6.5 is using the following version:
  # /usr/lib64/xen/bin/qemu-dm -help
  QEMU PC emulator version 0.10.2, Copyright (c) 2003-2008 Fabrice Bellard

  Greetings
  Uli Stärk

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1484925/+subscriptions

[Qemu-devel] [Bug 597575] Re: Hangs on HTTP errors when using the curl block driver

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/597575

Title:
  Hangs on HTTP errors when using the curl block driver

Status in QEMU:
  Expired

Bug description:
  Hi,

  It seems that qemu-kvm does not handle HTTP errors gracefully when
  using the curl block driver and a synchronous request is made (i.e.
  one using bdrv_read_em() for example). In these cases, if an HTTP
  error (such as 404 or 416) is returned, the aio thread exits but the
  main thread never finishes waiting for I/O completion, thus freezing
  KVM.

  Versions affected:
  At least 0.11.1 and 0.12.4 were tested and found to be affected.

  How to reproduce:
  Simply specify a non-existing path for an HTTP URL as a CDROM drive.
  kvm -drive file=test.img,format=qcow2,if=ide,index=0,boot=on -drive 
file=http://127.0.0.1/static/test1.iso,media=cdrom,index=2,if=ide -boot c

  qemu-kvm will hang on boot using 100% cpu as it will try to open the
  block device. At that point, the backtrace is (qemu-kvm-0.12.4):

  #0  0x0047aaaf in qemu_aio_wait () at aio.c:163
  #1  0x0047a055 in bdrv_read_em (bs=0x1592320, sector_num=0, 
buf=0x7fffcf7e9ae0 "¨\237~Ïÿ\177", nb_sectors=4)
  at block.c:1939
  #2  0x00479c0e in bdrv_pread (bs=0x1592320, offset=, buf=0x7fffcf7e9ae0, count1=2048)
  at block.c:716
  #3  0x0047a862 in bdrv_open2 (bs=0x1591a30, filename=0x1559f00 
"http://127.0.0.1/static/test1.iso;, 
  flags=0, drv=0x84eca0) at block.c:316
  #4  0x0040dcb4 in drive_init (opts=0x1559e60, opaque=, fatal_error=0x7fffcf7ea494)
  at 
/build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2471
  #5  0x0040e086 in drive_init_func (opts=0x155db00, opaque=0x0)
  at 
/build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:2488
  #6  0x00475421 in qemu_opts_foreach (list=, 
func=0x40e070 , 
  opaque=0x8495e0, abort_on_failure=12) at qemu-option.c:817
  #7  0x0040e9af in main (argc=7, argv=0x7fffcf7ea838, envp=)
  at 
/build/buildd-qemu-kvm_0.12.4+dfsg-1~bpo50+1-amd64-KOah5G/qemu-kvm-0.12.4+dfsg/vl.c:6011

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/597575/+subscriptions

[Qemu-devel] [Bug 697510] Re: Machine shut off after tons of lsi_scsi: error: MSG IN data too long

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697510

Title:
  Machine shut off after tons of lsi_scsi: error: MSG IN data too long

Status in QEMU:
  Expired

Bug description:
  The problem mostly happens during our backup, syslog does not have any
  problematic messages.

  Host is Ubuntu 10.10 x86 64 bits
  Guest is Windows 2003 Server 32 bits
  Using Virtio and Red Hat driver I get a STOP screen 0x10d1 and machine 
either reboot, stay frozen or shut off.
  Using SCSI the machine shuts off and I get tons of message on stdout;

  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 3500 -smp 
4,sockets=4,cores=1,threads=1 -name BMSRV0101 -uuid 
6ccbb5fa-5880-a1ab-3b7a-fb7ccc7c8ccf -nodefaults -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/BMSRV0101.monitor,server,nowait 
-mon chardev=monitor,mode=readline -rtc base=localtime -boot c -device 
lsi,id=scsi0,bus=pci.0,addr=0x4 -drive 
if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device 
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive 
file=/dev/vgUbuntu/vmBMSRV0101,if=none,id=drive-scsi0-0-0,boot=on,format=raw 
-device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 
-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:5d:7b:07,bus=pci.0,addr=0x3 
-net tap,fd=63,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device 
isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 
-vga cirrus -device usb-host,hostbus=002,hostaddr=005,id=hostdev0 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 
  char device redirected to /dev/pts/0
  pci_add_option_rom: failed to find romfile "pxe-virtio.bin"
  husb: open device 2.5
  husb: config #1 need -1
  husb: 1 interfaces claimed for configuration 1
  husb: grabbed usb device 2.5
  husb: config #1 need 1
  husb: 1 interfaces claimed for configuration 1

  lsi_scsi: error: Unimplemented message 0x00
  (x8)

  lsi_scsi: error: MSG IN data too long
  lsi_scsi: error: Unimplemented message 0x00
  (x760)

  lsi_scsi: error: MSG IN data too long
  lsi_scsi: error: MSG IN data too long
  kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: 
Assertion `s->current' failed.

  
  I can include minidump file if needed.
  I am currently using IDE and it seems OK.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/697510/+subscriptions

[Qemu-devel] [Bug 682360] Re: Unaccessible memory

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/682360

Title:
  Unaccessible memory

Status in QEMU:
  Expired

Bug description:
  Hello,

  I'm trying to develop a OS over L4/X2 microkernel and I use Linux
  debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-
  system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my
  kernel boots fine. If I modify this command line with -m 384M (for
  example), my kernel is loaded but enter in a deadlock. I have found a
  bug in my code until I have tried to use the _same_ disk image under
  virtualbox and it works without any trouble. I runs fine on a real PC
  also.

  I have bissected my code and qemu stops (maybe in a deadlock) when I try to 
access to memory :
  %MEM-I-VM_ALLOC, adding $00045000 - $00108FFF to VM allocator
  %MEM-I-VM_ALLOC, adding $0010B000 - $003F2FFF to VM allocator
  %MEM-I-VM_ALLOC, adding $0040C000 - $00FF to VM allocator
  %MEM-I-VM_ALLOC, adding $0100F000 - $FEFF to VM allocator
  %MEM-I-ACCMAP, accepting mapping
  %MEM-I-ACCMAP, virtual  $ - $0FFF
  %MEM-I-ACCMAP, physical $0009E000 - $0009EFFF

  Note that qemu doesn't crash. It only stops. My virtual memory
  subsystem maps $ in physical memory ($9E000). And when
  I try to initialize this memory, qemu enters in deadlock.

  A disk image to reproduce this bug is available at
  http://www.systella.fr/~bertrand/freevms.img.bz2

  Regards,

  JKB

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/682360/+subscriptions

[Qemu-devel] [Bug 682326] Re: linux-user/mmap exhaustion

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/682326

Title:
  linux-user/mmap exhaustion

Status in QEMU:
  Expired

Bug description:
  Currently when executing a linux-user target, mmap.c is in use- the
  model it uses internally for figuring out what the mmap address
  actually should be basically is an accumulator, every mmap invocation
  (regardless of munmap's that cleared the previous usage) is center on
  the next page.

  The end result of this is that it'll burn it's way through the space
  soon enough, especially if it's a 64bit host w/ a 32bit target- the
  host starts giving back 64bit addresses and the emulated mmap falls
  over after failed attempts at a low MAP_FIXED range.

  Where this becomes problematic is that glibc's FILE internals mmap a
  *lot*- once per handle.  Any long running process can hit this wall-
  rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so
  it hits the wall surprisingly fast- at least on an opensuse 11.2
  system w/ mmap_min_addr of 65536 (their default), building qt reliably
  hits that exhaustion during packaging.

  Attached is basically, a hack- but one that works surprisingly well
  and at least for meego building via qemu-arm, eliminates the failure
  scenario I've described above.  It doesn't remove the exhaustion as
  much as push it a fair bit back, although there are still a couple of
  ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the
  only remaining example I'm aware of).

  This patch simply checks to see if upon an actual, host level munmap,
  if the ending point of the munmap is where we'd allocate from next- if
  so, it shifts the starting point back to the (now) unmap'd start,
  reusing the space.  Rebuilding meego a couple of times over, thus far
  I've not managed to flush out any failures that point at this specific
  patch, so... it looks like it's doing the trick- that said the lack of
  a g2h/h2g in the calculation still seems questionable to me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/682326/+subscriptions

[Qemu-devel] [Bug 696530] Re: qemu-0.13.0-r2 special keys different when using -alt-grab

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/696530

Title:
  qemu-0.13.0-r2 special keys different when using -alt-grab

Status in QEMU:
  Expired

Bug description:
  I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f
  for full screen did not work for me with a windows guest. They work
  normally when omitting the -alt-grab startup parameter.

  After quite a long time, I found out that I have to add the shift key
  to the keys from the documentation when I use the -alt-grab option.

  Probably -ctrl-grab behaves similarly. It would be really nice to have
  this documented in the default documentation in the man page as has
  not been documented there yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/696530/+subscriptions