diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1721 | 77 | ||||
| -rw-r--r-- | results/classifier/108/other/1721221 | 106 | ||||
| -rw-r--r-- | results/classifier/108/other/1721275 | 102 | ||||
| -rw-r--r-- | results/classifier/108/other/1721744 | 98 | ||||
| -rw-r--r-- | results/classifier/108/other/1721788 | 105 | ||||
| -rw-r--r-- | results/classifier/108/other/1721952 | 59 |
6 files changed, 547 insertions, 0 deletions
diff --git a/results/classifier/108/other/1721 b/results/classifier/108/other/1721 new file mode 100644 index 00000000..eee32031 --- /dev/null +++ b/results/classifier/108/other/1721 @@ -0,0 +1,77 @@ +other: 0.900 +PID: 0.870 +permissions: 0.860 +graphic: 0.852 +semantic: 0.838 +device: 0.833 +files: 0.826 +socket: 0.826 +KVM: 0.822 +vnc: 0.797 +debug: 0.788 +performance: 0.730 +boot: 0.720 +network: 0.645 + +Problem in combination with RabbitMQ and erlang +Description of problem: +I have a problem with rabbitMQ /erlang / Qemu on my local system. + +I use docker with: + +version: "3.6" +``` +services: + rabbitmq: + image: rabbitmq:3-management +``` + +Docker Desktop 4.20.1 (110738) +Docker version 24.0.2, build cb74dfc + +Apple Macbook Pro with M1 Chip Ventura 13.4. + +I deleted all containers and images related to rabbitMQ. Then when I do a: docker compose up -d + +I always get this error and rabbitMQ stopps: + +``` +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:18.984151+00:00 [notice] <0.44.0> Application mnesia exited with reason: stopped +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.658039+00:00 [info] <0.230.0> Waiting for Mnesia tables for 30000 ms, 9 retries left +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.659274+00:00 [info] <0.230.0> Successfully synced tables from a peer +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.662647+00:00 [notice] <0.283.0> Feature flags: attempt to enable `stream_sac_coordinator_unblock_group`... +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.793670+00:00 [notice] <0.283.0> Feature flags: `stream_sac_coordinator_unblock_group` enabled +rabbitmq-server-rabbitmq-1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped +rabbitmq-server-rabbitmq-1 | Segmentation fault +``` + +In the past it worked, like 5 months ago. + +Reproduction steps docker compose up -d + +Expected behavior that the container runs and does not exit + +Additional context docker compose logs + +``` +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.946635+00:00 [notice] <0.44.0> Application syslog exited with reason: stopped +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.966134+00:00 [notice] <0.230.0> Logging: switching to configured handler(s); following messages may not be visible in this log output +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.973002+00:00 [notice] <0.230.0> Logging: configured log handlers are now ACTIVE +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539052+00:00 [info] <0.230.0> ra: starting system quorum_queues +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539748+00:00 [info] <0.230.0> starting Ra system: quorum_queues in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/quorum/rabbit@4fb71bcd203a +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.715984+00:00 [info] <0.261.0> ra system 'quorum_queues' running pre init for 0 registered servers +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.749375+00:00 [info] <0.262.0> ra: meta data store initialised for system quorum_queues. 0 record(s) recovered +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.786151+00:00 [notice] <0.267.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857344+00:00 [info] <0.230.0> ra: starting system coordination +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857635+00:00 [info] <0.230.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/coordination/rabbit@4fb71bcd203a +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.868808+00:00 [info] <0.274.0> ra system 'coordination' running pre init for 0 registered servers +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.874965+00:00 [info] <0.275.0> ra: meta data store initialised for system coordination. 0 record(s) recovered +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.875747+00:00 [notice] <0.280.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Starting RabbitMQ 3.12.0 on Erlang 25.3.2.2 [jit] +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Copyright (c) 2007-2023 VMware, Inc. or its affiliates. +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com +rabbitmq-server-rabbitmq-1 | +rabbitmq-server-rabbitmq-1 | +Additional information: + diff --git a/results/classifier/108/other/1721221 b/results/classifier/108/other/1721221 new file mode 100644 index 00000000..51b90322 --- /dev/null +++ b/results/classifier/108/other/1721221 @@ -0,0 +1,106 @@ +vnc: 0.703 +other: 0.701 +KVM: 0.698 +boot: 0.665 +files: 0.665 +device: 0.656 +debug: 0.648 +permissions: 0.647 +performance: 0.644 +semantic: 0.637 +socket: 0.635 +graphic: 0.620 +network: 0.605 +PID: 0.584 + +PCI-E passthrough of Nvidia GTX GFX card to Win 10 guest fails with "kvm_set_phys_mem: error registering slot: Invalid argument" + +Problem: +Passthrough of a PCI-E Nvidia GTX 970 GFX card to a Windows 10 guest from a Debian Stretch host fails after recent changes to kvm in QEMU master/trunk. Before this recent commit, everything worked as expected. + +QEMU Version: +Master/trunk pulled from github 4/10/17 ( git reflog: d147f7e815 HEAD@{0} ) + +Host: +Debian Stretch kernel SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux + +Guest: +Windows 10 Professional + +Issue is with this commit: +https://github.com/qemu/qemu/commit/f357f564be0bd45245b3ccfbbe20ace08fe83ca8 + +Subsequent commit does not help: +https://github.com/qemu/qemu/commit/3110cdbd8a4845c5b5fb861b0a664c56d993dd3c#diff-7b7a17f6e8ba4195198dd685073f43cb + +Error output from qemu: +(qemu) kvm_set_phys_mem: error registering slot: Invalid argument + +QEMU commandline used: + +./sources/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm -serial none -parallel none -name Windows \ +-enable-kvm -cpu host,kvm=off,hv_vendor_id=sugoidesu,-hypervisor -smp 6,sockets=1,cores=3,threads=2 \ +-m 8G -mem-path /dev/hugepages -mem-prealloc -balloon none \ +-drive if=pflash,format=raw,readonly,file=vms/ovmf-x64/ovmf-x64/OVMF_CODE-pure-efi.fd \ +-drive if=pflash,format=raw,file=vms/ovmf-x64/ovmf-x64/OVMF_VARS-pure-efi.fd \ +-rtc clock=host,base=localtime \ +-readconfig ./vms/q35-virtio-graphical.cfg \ +-object iothread,id=iothread0 -object iothread,id=iothread1 -object iothread,id=iothread2 -object iothread,id=iothread3 \ +-device virtio-scsi-pci,iothread=iothread0,id=scsi0 -device virtio-scsi-pci,iothread=iothread1,id=scsi1 -device virtio-scsi-pci,iothread=iothread2,id=scsi2 -device virtio-scsi-pci,iothread=iothread3,id=scsi3 \ +-device scsi-hd,bus=scsi0.0,drive=drive0,bootindex=1 -device scsi-hd,bus=scsi1.0,drive=drive1 -device scsi-hd,bus=scsi2.0,drive=drive2 -device scsi-hd,bus=scsi3.0,drive=drive3 -device scsi-hd,bus=scsi1.0,drive=drive4 -device scsi-hd,bus=scsi2.0,drive=drive5 -device scsi-hd,bus=scsi3.0,drive=drive6 -device scsi-hd,bus=scsi1.0,drive=drive7 -device scsi-hd,bus=scsi2.0,drive=drive8 -device scsi-hd,bus=scsi3.0,drive=drive9 \ +-drive if=none,id=drive0,file=vms/w10p64.qcow2,format=qcow2,cache=none,discard=unmap \ +-drive if=none,id=drive1,file=vms/w10p64-2.qcow2,format=qcow2,cache=none,discard=unmap \ +-drive if=none,id=drive2,file=/dev/mapper/w10p64-3,format=raw,cache=none \ +-drive if=none,id=drive3,file=vms/w10p64-4.qcow2,format=qcow2,cache=none \ +-drive if=none,id=drive4,file=vms/w10p64-5.qcow2,format=qcow2,cache=none \ +-drive if=none,id=drive5,file=vms/w10p64-6.qcow2,format=qcow2,cache=none,discard=unmap \ +-drive if=none,id=drive6,file=/dev/mapper/w10p64-7,format=raw,cache=none \ +-drive if=none,id=drive7,file=vms/w10p64-8.qcow2,format=qcow2,cache=none,discard=unmap \ +-device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \ +-device vfio-pci,host=01:00.1,multifunction=on \ +-netdev type=tap,id=net1,ifname=tap1,script=no,downscript=no,vhost=on \ +-device virtio-net-pci,netdev=net1,mac=52:54:00:18:32:c9,bus=pcie.2,addr=00.0,ioeventfd=on \ +-device usb-host,bus=usb.0,hostbus=3,hostport=2.1 \ +-device usb-host,hostbus=3,hostport=2.2 \ +-device usb-host,bus=ich9-ehci-1.0,hostbus=3,hostport=2.4 \ +-object input-linux,id=kbd1,evdev=/dev/input/event0,grab_all=yes,repeat=on \ +-drive if=none,id=drive8,file=vms/w10p64.qcow2-9,format=qcow2,discard=unmap \ +-drive if=none,id=drive9,file=vms/w10p64-10.qcow2,format=qcow2,cache=none,discard=unmap \ +-device usb-host,bus=usb.0,hostbus=3,hostport=9 \ +-monitor stdio + +lspci -tv +-[0000:00]-+-00.0 Intel Corporation 4th Gen Core Processor DRAM Controller + +-01.0-[01]--+-00.0 NVIDIA Corporation GM204 [GeForce GTX 970] + | \-00.1 NVIDIA Corporation GM204 High Definition Audio Controller + +-02.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller + +-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller + +-14.0 Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI + +-16.0 Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 + +-19.0 Intel Corporation Ethernet Connection I217-V + +-1a.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 + +-1b.0 Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller + +-1c.0-[02]-- + +-1c.3-[03]----00.0 Broadcom Limited BCM4352 802.11ac Wireless Network Adapter + +-1d.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 + +-1f.0 Intel Corporation Z87 Express LPC Controller + +-1f.2 Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] + \-1f.3 Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller + + +I should probably add that I am using a recent OVMF firmware from this repo: https://www.kraxel.org/repos/jenkins/edk2/ namely edk2.git-ovmf-x64-0-20170914.b2974.g7f2f96f1a8.noarch.rpm dated 18/9/17 + +There's another bug report / discussion thread on qemu-devel about the same commit: + +http://<email address hidden> + +I'll add a note to that thread about this LP report too. + +Apologies, the title of this bug might be very misleading. I've made a huge assumption that PCI-E GFX card pass-through was triggering the bug, purely because a Debian Stretch guest VM on the same host, using the same build of QEMU, which uses virtio-vga for graphics and the same version of OVMF firmware, boots up fine. + +More noise... OK, so I've tested the Windows 10 guest VM using the same criteria but eliminating PCI-E pass-through and using virtio-vga graphics instead, and the the guest boots up fine so perhaps my assumption is correct. + +Let me know if you need to see the memory I/O regions or dmesg of my host etc. + +Fix will end up in QEMU master soon. + diff --git a/results/classifier/108/other/1721275 b/results/classifier/108/other/1721275 new file mode 100644 index 00000000..6241c873 --- /dev/null +++ b/results/classifier/108/other/1721275 @@ -0,0 +1,102 @@ +other: 0.733 +PID: 0.720 +permissions: 0.707 +device: 0.695 +vnc: 0.673 +performance: 0.628 +semantic: 0.609 +graphic: 0.575 +boot: 0.559 +files: 0.551 +debug: 0.538 +socket: 0.533 +network: 0.449 +KVM: 0.415 + +Support more ARM CPUs + +Hi, + +This is an enhancement request, rather than a bug report. + +After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters. + +I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for. + +I'd like to have: +cortex-m0 +cortex-m4 +cortex-m7 +cortex-m23 +cortex-m33 + +cortex-a35 +cortex-a53 +cortex-a57 + +Is it possible? +Is it the right place to ask? +Should I file separate requests for each? + +Thanks + +M0 is hard, because it's v6M which we don't support. M4 we already have (but only the no-fpu variant). M7 we don't currently have -- what would be the differences from M4? M33 is in the works (it's v8M). M23 is harder, because it's v8M-baseline which is the v8M equivalent to v6M. A53 and A57 we already have. How would A35 differ from A53/A57 ? + + +PS: in general I wouldn't unconditionally trust that QEMU emulating CPU X definitely does not implement any instructions that CPU X doesn't have -- no real world code will notice, and we don't have any mechanism to automatically verify that we didn't accidentally forget to conditionalize an instruction on an architecture feature. + + +Thanks for PS, I thought QEMU was stricter than that. + +Regarding M7 vs M$ or A35 vs A53/A57, even though there's no functional difference, it would be convenient in Makefiles to have CPU=cortex-a53, and use $(CPU) to expand GCC and QEMU options, without having to guess which CPU I should use for QEMU that would match the one I pass to GCC. + +Regarding v[68]M, are there any plans to add support for these variants to QEMU? + + +On 16 October 2017 at 14:16, Christophe Lyon +<email address hidden> wrote: +> Thanks for PS, I thought QEMU was stricter than that. + +Well, I hope we get it right, and we'll treat cases where +we get it wrong as bugs, but we're not testing... + +> Regarding v[68]M, are there any plans to add support for these variants +> to QEMU? + +v8M we're working on. v6M we have no plans for currently. + +thankns +-- PMM + + +We now support Cortex-M0 (v6M) and Cortex-M33 (v8M mainline). We don't have Cortex-M7, Cortex-M23 (v8M baseline) or Cortex-A35. + +In general, adding an extra CPU to QEMU really requires us to have a decent use-case for it, probably including a board model for it, especially for the M-profile CPUs. There are a lot of CPUs out there and I'm not too keen on adding large numbers of them unless there's a real need. + +I'm going to close this bug report because I don't think it really adds anything to have it sitting open indefinitely. + + +Regarding Cortex-M7, I've noticed that unlike Cortex-M4, it supports double precision floating-point. Is DP supported by qemu? + + +Yes, QEMU supports DP (I actually had to go to some lengths to disable the DP support for the M4 :-)) + + +How do I activate it since --cpu cortex-m7 isn't supported? + +You can't for an M-profile CPU. It would work without any further coding beyond getting the ID register values right if we had a Cortex-M7 model, though. + + +It seemed "easy" to add cortex-m7 based on cortex-m4 (copy m4 description, update ID register values), but I realized that QEMU does not support FPv5 which not only supports DP, but also adds new instructions that QEMU does not handle yet (see section A2.5 of the ARMv7-M ARM). + +* Are there plans to implement them? +* If not, how difficult is it? (for a developer not very familiar with the QEMU code base) + + +They are implemented, because they also appear in A-profile. +We just need to set the corresponding MVFR field to enable them. + +Setting MVFR2.FPMISC = 4 will do the job, I believe. + +Good news, I thought at least some of them were not implemented because for instance I couldn't find where VRINTA is handled (I noticed code for NEON_2RM_VRINTA, but I thought there should be something in vfp.decode for VRINT[ANPM]) + diff --git a/results/classifier/108/other/1721744 b/results/classifier/108/other/1721744 new file mode 100644 index 00000000..1ff666b4 --- /dev/null +++ b/results/classifier/108/other/1721744 @@ -0,0 +1,98 @@ +graphic: 0.803 +semantic: 0.799 +other: 0.771 +debug: 0.728 +PID: 0.717 +permissions: 0.715 +performance: 0.611 +boot: 0.599 +KVM: 0.586 +device: 0.575 +vnc: 0.561 +network: 0.525 +socket: 0.477 +files: 0.476 + +Help content missing for newly added machine properties + + +Help content missing for newly added machine properties, it would be needed by libvirt and other management layers to query to add support, Thanks. + +max-cpu-compat,vsmt,modern-hotplug-events,resize-hpt + +Steps: +1. Compile qemu @below commit +2. ./ppc64-softmmu/qemu-system-ppc64 -h +.... +-machine [type=]name[,prop[=value][,...]] + selects emulated machine ('-machine help' for list) + property accel=accel1[:accel2[:...]] selects accelerator + supported accelerators are kvm, xen, hax or tcg (default: tcg) + kernel_irqchip=on|off|split controls accelerated irqchip support (default=off) + vmport=on|off|auto controls emulation of vmport (default: auto) + kvm_shadow_mem=size of KVM shadow MMU in bytes + dump-guest-core=on|off include guest memory in a core dump (default=on) + mem-merge=on|off controls memory merge support (default: on) + igd-passthru=on|off controls IGD GFX passthrough support (default=off) + aes-key-wrap=on|off controls support for AES key wrapping (default=on) + dea-key-wrap=on|off controls support for DEA key wrapping (default=on) + suppress-vmdesc=on|off disables self-describing migration (default=off) + nvdimm=on|off controls NVDIMM support (default=off) + enforce-config-section=on|off enforce configuration section migration (default=off) + s390-squash-mcss=on|off controls support for squashing into default css (default=off) +.... + +===> Not showing help of mentioned properties. + + + +Verified at todays below commit +#git show +commit d8f932cc696250cb740240d668b39df5fbb2d5a0 +Merge: 67caeea 4504273 +Author: Peter Maydell <email address hidden> +Date: Thu Oct 5 16:54:29 2017 +0100 + + Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging + + # gpg: Signature made Thu 05 Oct 2017 15:25:21 BST + # gpg: using RSA key 0x9CA4ABB381AB73C8 + # gpg: Good signature from "Stefan Hajnoczi <email address hidden>" + # gpg: aka "Stefan Hajnoczi <email address hidden>" + # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 + + * remotes/stefanha/tags/tracing-pull-request: + checkpatch: fix incompatibility with old perl + + Signed-off-by: Peter Maydell <email address hidden> + +Hmm... -h is common to all targets, ie, you should only find properties that can be passed to -machine for all qemu-system-* binaries (I don't know how s390-squash-mcss landed there but it looks wrong). + +The right way to query properties supported by a pseries machine type is: + +$ ./ppc64-softmmu/qemu-system-ppc64 -machine pseries,help +pseries-2.11.kvm-type=string (Specifies the KVM virtualization mode (HV, PR)) +pseries-2.11.vsmt=uint32 (Virtual SMT: KVM behaves as if this were the host's SMT mode) +pseries-2.11.modern-hotplug-events=bool (Use dedicated hotplug event mechanism in place of standard EPOW events when possible (required for memory hot-unplug support)) +pseries-2.11.max-cpu-compat=string (Maximum permitted CPU compatibility mode. Valid values are power6, power7, power7+, power8, power9.) +pseries-2.11.resize-hpt=string (Resizing of the Hash Page Table (enabled, disabled, required)) +pseries-2.11.kvm-shadow-mem=int (KVM shadow MMU size) +pseries-2.11.enforce-config-section=bool (Set on to enforce configuration section migration) +pseries-2.11.initrd=string (Linux initial ramdisk file) +pseries-2.11.mem-merge=bool (Enable/disable memory merge support) +pseries-2.11.firmware=string (Firmware image) +pseries-2.11.dtb=string (Linux kernel device tree file) +pseries-2.11.suppress-vmdesc=bool (Set on to disable self-describing migration) +pseries-2.11.usb=bool (Set on/off to enable/disable usb) +pseries-2.11.kernel=string (Linux kernel image file) +pseries-2.11.dt-compatible=string (Overrides the "compatible" property of the dt root node) +pseries-2.11.igd-passthru=bool (Set on/off to enable/disable igd passthrou) +pseries-2.11.dumpdtb=string (Dump current dtb to a file and quit) +pseries-2.11.append=string (Linux kernel command line) +pseries-2.11.accel=string (Accelerator list) +pseries-2.11.kernel-irqchip=OnOffSplit (Configure KVM in-kernel irqchip) +pseries-2.11.dump-guest-core=bool (Include guest memory in a core dump) +pseries-2.11.phandle-start=int (The first phandle ID we may generate dynamically) +pseries-2.11.graphics=bool (Set on/off to enable/disable graphics emulation) + + diff --git a/results/classifier/108/other/1721788 b/results/classifier/108/other/1721788 new file mode 100644 index 00000000..d8874760 --- /dev/null +++ b/results/classifier/108/other/1721788 @@ -0,0 +1,105 @@ +permissions: 0.746 +network: 0.717 +semantic: 0.668 +graphic: 0.629 +device: 0.606 +PID: 0.605 +other: 0.600 +KVM: 0.528 +debug: 0.522 +files: 0.518 +socket: 0.503 +vnc: 0.496 +boot: 0.492 +performance: 0.486 + +Failed to get shared "write" lock with 'qemu-img info' + +When running 'qemu-img info test.qcow2' while test.qcow2 is currently used by a Qemu process, I get the error + +qemu-img: Could not open 'test.qcow2': Failed to get shared "write" lock. + + +Why does displaying information about a disk image need a write lock for the file? + +Steps to reproduce: + +qemu-img create -f qcow2 test.qcow2 10M +qemu-system-x86_64 -nographic -drive file=test.qcow2 +qemu-img info test.qcow2 + +The above was tested with Qemu version 2.10.0 + +The QEMU process that has the disk image open may be doing I/O that causes qcow2 metadata to be changed. Such changes could confuse the 'qemu-img' process it is was reading the metadata at the same time it was being changed, causing bad data to be printed or worse. So requiring a write lock is the 'safe' thing to do for reliability in the worst case. You can override this by passing '--force-share' arg though. + +I've just noticed, however, that '--force-share' appears totally undocumented in both CLI help output and the man page. So that's certainly something that should be fixed + +On 10/06/2017 09:09 AM, Jan Heidbrink wrote: +> Public bug reported: +> +> When running 'qemu-img info test.qcow2' while test.qcow2 is currently +> used by a Qemu process, I get the error +> +> qemu-img: Could not open 'test.qcow2': Failed to get shared "write" +> lock. +> +> +> Why does displaying information about a disk image need a write lock for the file? + +Because there is a risk (albeit rather slight) that what you read from +the disk is inconsistent due to being an intermediate state in-between +separate non-atomic write actions by the other process that has it open +for write. + +If you are willing to ignore the risk, then use: + +qemu-img info -U test.qcow2 + +which says that you are okay reading the image while it is shared with a +concurrent writer, even if the read fails spectacularly in the unlikely +case that it sees inconsistent information. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + + +This does not only affect qemu-img only, it could not make libvirt +"<shareable>" work either when two vms were running with share disk +image. Is there a workaround for this situation? + +Best, +Liang + +On 10/6/17 10:30 AM, Daniel Berrange wrote: +> I've just noticed, however, that '--force-share' appears totally +> undocumented in both CLI help output and the man page. So that's +> certainly something that should be fixed +> + + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +Hi, + +What exactly is the problem now? As Eric explained in comment 3, "qemu-img info -U" is what needs to be used here. Daniel raised the problem of --force-share/-U being undocumented, but that’s no longer the case as of commit a7e326df1c116e99e, which was first included in the 2.12.0 release. + +Max + +Ah ok, I think this bug can be closed then. + +I have the same problem + diff --git a/results/classifier/108/other/1721952 b/results/classifier/108/other/1721952 new file mode 100644 index 00000000..ede49bb5 --- /dev/null +++ b/results/classifier/108/other/1721952 @@ -0,0 +1,59 @@ +other: 0.758 +network: 0.681 +permissions: 0.674 +PID: 0.665 +device: 0.663 +socket: 0.659 +debug: 0.655 +vnc: 0.628 +semantic: 0.622 +performance: 0.590 +graphic: 0.580 +KVM: 0.543 +boot: 0.535 +files: 0.535 + +Network issue above 2.5.1.1 + +Hi, +WHen running a QEMU guest (Windows7) on a linux x86-64 server, the network stops working after some time for any version above 2.5.1.1 + +In 2.5.1.1, all is fine (no issue with network) +Any version ablve (trying 2.10.1 now), the application in windows stops accessing the internet after a while + +THis is my starting line: +/usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winpro.qcow,index=0,media=disk,format=qco +w2 -m 4096 -vga vmware -vnc :3 -k en-us -device e1000,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfwd=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemon +ize + +Thisis my configure line: +./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-kvm --disable-gtk --disable-xen --disable-user --enable-vnc-sasl --disable-libusb --disable-debug-info --disable-spi +ce --enable-lzo --enable-pie --disable-werror --enable-linux-aio --enable-vhost-net --disable-tcmalloc --enable-vde --enable-nettle --disable-smartcard --enable-curl + +On Sat, Oct 07, 2017 at 12:09:25PM -0000, Joan Moreau via Qemu-devel wrote: +> WHen running a QEMU guest (Windows7) on a linux x86-64 server, the network stops working after some time for any version above 2.5.1.1 +> +> In 2.5.1.1, all is fine (no issue with network) +> Any version ablve (trying 2.10.1 now), the application in windows stops accessing the internet after a while +> +> THis is my starting line: +> /usr/bin/qemu-system-x86_64 -machine pc-i440fx-1.7,accel=kvm -usb -usbdevice tablet -usbdevice keyboard -enable-kvm -cpu core2duo -smp 2 -drive file=winpro.qcow,index=0,media=disk,format=qco +> w2 -m 4096 -vga vmware -vnc :3 -k en-us -device e1000,netdev=nic1 -netdev user,id=nic1,smb=/data/vps/files/,hostfwd=tcp::10053-:10053,hostfwd=tcp::3387-:3389 -rtc base=utc,clock=host -daemon +> ize +> +> Thisis my configure line: +> ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-kvm --disable-gtk --disable-xen --disable-user --enable-vnc-sasl --disable-libusb --disable-debug-info --disable-spi +> ce --enable-lzo --enable-pie --disable-werror --enable-linux-aio --enable-vhost-net --disable-tcmalloc --enable-vde --enable-nettle --disable-smartcard --enable-curl + +Does tcpdump on the host show outgoing connections to an external IP +address (not a domain name)? For example, try opening to +http://172.99.69.163/ from inside the guest and check that there is a +TCP SYN packet sent from the host to 172.99.69.163. + +Do the hostfwd ports still work while internet access is down? + +Stefan + + +[Expired for QEMU because there has been no activity for 60 days.] + |