diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/153 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1530035 | 44 | ||||
| -rw-r--r-- | results/classifier/108/other/1530278 | 33 | ||||
| -rw-r--r-- | results/classifier/108/other/1530386 | 51 | ||||
| -rw-r--r-- | results/classifier/108/other/1531 | 30 | ||||
| -rw-r--r-- | results/classifier/108/other/1531352 | 27 | ||||
| -rw-r--r-- | results/classifier/108/other/1532 | 518 | ||||
| -rw-r--r-- | results/classifier/108/other/1533141 | 43 | ||||
| -rw-r--r-- | results/classifier/108/other/1533848 | 21 | ||||
| -rw-r--r-- | results/classifier/108/other/1534 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1534382 | 46 | ||||
| -rw-r--r-- | results/classifier/108/other/1534978 | 41 | ||||
| -rw-r--r-- | results/classifier/108/other/1535497 | 44 | ||||
| -rw-r--r-- | results/classifier/108/other/1536487 | 101 | ||||
| -rw-r--r-- | results/classifier/108/other/1538 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1538541 | 80 | ||||
| -rw-r--r-- | results/classifier/108/other/1539 | 18 |
17 files changed, 1145 insertions, 0 deletions
diff --git a/results/classifier/108/other/153 b/results/classifier/108/other/153 new file mode 100644 index 000000000..6b7f9a08a --- /dev/null +++ b/results/classifier/108/other/153 @@ -0,0 +1,16 @@ +device: 0.918 +performance: 0.714 +debug: 0.491 +semantic: 0.428 +files: 0.281 +network: 0.239 +boot: 0.135 +vnc: 0.092 +other: 0.081 +permissions: 0.046 +socket: 0.024 +graphic: 0.017 +PID: 0.009 +KVM: 0.001 + +SLIRP SMB silently fails with MacOS smbd diff --git a/results/classifier/108/other/1530035 b/results/classifier/108/other/1530035 new file mode 100644 index 000000000..cf91a5886 --- /dev/null +++ b/results/classifier/108/other/1530035 @@ -0,0 +1,44 @@ +graphic: 0.891 +device: 0.887 +PID: 0.869 +other: 0.796 +performance: 0.793 +semantic: 0.785 +files: 0.769 +network: 0.750 +socket: 0.696 +KVM: 0.686 +permissions: 0.680 +debug: 0.671 +vnc: 0.636 +boot: 0.622 + +usb-host: ATI Technologies, Inc. TV Wonder acts as a different device if used + +Title says it all. If you try to use the "ATI Technologies, Inc. TV Wonder" USB 1.1 TV Tuner for passthrough under any OS that has drivers for the device, the usb-host driver will confuse itself and give the device a new PID number for Linux. + +Tested on ReactOS and Windows XP with stable QEMU package from pacman on Arch Linux. + +Commands used: sudo qemu-system-x86_64 -enable-kvm -hda ~/QEMU/hd/winxp.img -usb -device usb-host,hostbus=2,hostaddr=3 -vga vmware + +Before starting qemu-kvm, lsusb reports: +[ +Bus 002 Device 003: ID 0528:7561 ATI Technologies, Inc. TV Wonder +] + +After starting qemu-kvm, usb-host and lsusb report: +[ +libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/003: No such file or directory + +The device in Bus 2, Device 3 is gone and it appears as this instead: +Bus 002 Device 005: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) D-Link V100 +] + +This weird effect only lasts until you unplug the TV Wonder. + +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 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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1530278 b/results/classifier/108/other/1530278 new file mode 100644 index 000000000..f4d78f521 --- /dev/null +++ b/results/classifier/108/other/1530278 @@ -0,0 +1,33 @@ +graphic: 0.892 +socket: 0.834 +boot: 0.812 +network: 0.808 +device: 0.802 +semantic: 0.726 +permissions: 0.703 +performance: 0.694 +vnc: 0.676 +KVM: 0.650 +PID: 0.635 +files: 0.612 +debug: 0.596 +other: 0.522 + +vhost-user: can not detach chardev which is used by vhost-user backend + +I launch a VM which use vhost-user netdevice as follows.When detach the netdevice in qemu monitor, the chardevice which used by the netdevice also should be deatched.The netdevice can be detached sucessfully.But the chardevice failed when it was being detaching. +Full command line : +qemu-system-x86_64 \ +-cpu host -boot c -hda /home/lining/ubuntu_12_04.img -snapshot -m 2048 -smp 2 \ +--enable-kvm -name "client1" -vnc :1 \ +-object memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem \ +-chardev socket,id=chr1,path=/opt/network/ovdk/bin/vhost-user \ +-netdev vhost-user,id=net12,chardev=chr1,ifname=port80, vhostforce \ +-device virtio-net-pci,netdev=net12,mac=00:00:00:00:00:01,\ +csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off,any_layout=off + +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 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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1530386 b/results/classifier/108/other/1530386 new file mode 100644 index 000000000..c6ebe6741 --- /dev/null +++ b/results/classifier/108/other/1530386 @@ -0,0 +1,51 @@ +graphic: 0.916 +performance: 0.802 +device: 0.783 +boot: 0.726 +semantic: 0.684 +PID: 0.674 +socket: 0.663 +debug: 0.652 +files: 0.629 +other: 0.602 +vnc: 0.580 +network: 0.561 +permissions: 0.557 +KVM: 0.067 + +command.com on win95 throws video mode out + +on a presumed-good copy of Windows 95 obtained from http://forum.xda-developers.com/showthread.php?t=1960870, the operating system boots successfully and shows up fine, but as soon as I double-click the MS-DOS icon, the window, while remaining the same size, goes to a different resolution and only shows a small portion of what it did, with strange colors and artifacts. tried first with the Debian 2.5 package, then with latest cvs sources, then with the 2.5.0 release, all the same problem. + +jcomeau@aspire:/usr/src/qemu-2.5.0/build$ cd /tmp/win95/SDL/ +jcomeau@aspire:/tmp/win95/SDL$ /usr/src/qemu-2.5.0/build/i386-softmmu/qemu-system-i386 c.img +jcomeau@aspire:/tmp/win95/SDL$ /usr/src/qemu-2.5.0/build/i386-softmmu/qemu-system-i386 --version +QEMU emulator version 2.5.0, Copyright (c) 2003-2008 Fabrice Bellard + + + +verified that the problem does not exist on bochs version 2.6-5 Debian package. I first had to convert the image from qcow to raw: qemu-img convert -O raw c.img c_raw.img + +bxrc file: + +megs: 32 +vga: extension=vbe +romimage: file=$BXSHARE/BIOS-bochs-latest +vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest +cpu: count=1, ips=100000000, reset_on_triple_fault=1 +boot: disk +ata0-master: type=disk, path="/tmp/c_raw.img" +#info: action=report +#debug: action=report +log: /tmp/bochs-win95.log +mouse: enabled=0 +vga_update_interval: 150000 + +command line: bochs -q -f /tmp/bochs.bxrc + +screenshot attached. + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1531 b/results/classifier/108/other/1531 new file mode 100644 index 000000000..bc6174ac1 --- /dev/null +++ b/results/classifier/108/other/1531 @@ -0,0 +1,30 @@ +graphic: 0.693 +device: 0.692 +performance: 0.601 +socket: 0.568 +semantic: 0.564 +files: 0.563 +network: 0.486 +PID: 0.420 +boot: 0.374 +permissions: 0.363 +vnc: 0.338 +other: 0.304 +debug: 0.232 +KVM: 0.069 + +MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 +Description of problem: +Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. +Steps to reproduce: +1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) +2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) +3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 +4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts +Additional information: +The pre-built binary and its output file are attached as test.tar.gz +[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) + +Please note, that standalone cross-compiler for MIPS downloaded from the site +(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) +comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/results/classifier/108/other/1531352 b/results/classifier/108/other/1531352 new file mode 100644 index 000000000..238c71c10 --- /dev/null +++ b/results/classifier/108/other/1531352 @@ -0,0 +1,27 @@ +device: 0.738 +graphic: 0.719 +performance: 0.629 +PID: 0.591 +semantic: 0.576 +network: 0.562 +permissions: 0.541 +files: 0.498 +boot: 0.472 +vnc: 0.425 +debug: 0.419 +socket: 0.385 +KVM: 0.355 +other: 0.354 + +QEMU_LD_PREFIX not load correct library order in the PATH + +run qemu with QEMU_LD_PREFIX argument will not load the library in the PATH. +Ex: I use debootstrap to download the library of i386 architecture +And use -L point to the path. +But not load the library from that directory. + +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 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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1532 b/results/classifier/108/other/1532 new file mode 100644 index 000000000..c59bf61ca --- /dev/null +++ b/results/classifier/108/other/1532 @@ -0,0 +1,518 @@ +KVM: 0.904 +permissions: 0.898 +device: 0.850 +vnc: 0.848 +network: 0.842 +files: 0.840 +other: 0.831 +graphic: 0.818 +performance: 0.805 +PID: 0.804 +boot: 0.803 +debug: 0.783 +semantic: 0.720 +socket: 0.684 + +libivrtd fork qemu to create vm ,which start with ceph rbd device, after vm status:runing , the qemu stuck at booting from hard disk.... +Description of problem: +[root@ceph-client ceph]# virsh list --all + Id Name State +---------------------------------------------------- + 19 c7_ceph running + +the vm qemu stuck at booting from hard disk..... +Steps to reproduce: +1. use ceph-deploy deploy a ceph distribute storage, which use to store vm's qcow2 files,this ceph has 3 osd node +2. refer the link https://docs.ceph.com/en/quincy/rbd/libvirt/ create a ceph user :client.libvirt +3. import a exists qcow2 file into ceph libvit-pool, then start vm + +[root@ceph-1 ~]# ceph -s + cluster: + id: 3fbbf51f-88fd-4883-9f24-595bf853c5f2 + health: HEALTH_OK + + services: + mon: 1 daemons, quorum ceph-1 + mgr: ceph-1(active) + osd: 3 osds: 3 up, 3 in + + data: + pools: 1 pools, 128 pgs + objects: 940 objects, 3.6 GiB + usage: 31 GiB used, 209 GiB / 240 GiB avail + pgs: 128 active+clean + +[root@ceph-1 ~]#ceph auth ls +client.libvirt + key: AQD/XwFkq7kHMhAA1OmPtKPVno6gjmZleOevOA== + caps: [mon] allow r + caps: [osd] allow class-read object_prefix rbd_children, allow rwx pool=libvirt-pool + +[root@ceph-client ceph]# cat ceph.conf +[global] +fsid = 3fbbf51f-88fd-4883-9f24-595bf853c5f2 +mon_initial_members = ceph-1 +mon_host = 172.24.193.62 +auth_cluster_required = cephx +auth_service_required = cephx +auth_client_required = cephx + +osd_pool_default_size = 2 +[root@ceph-client ceph]# + +[root@ceph-client ceph]# virsh start c7_ceph +Domain c7_ceph started + +[root@ceph-client ceph]# +[root@ceph-client ceph]# virsh list --all + Id Name State +---------------------------------------------------- + 19 c7_ceph running + + + <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator> + <disk type='network' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <auth username='libvirt'> + <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/> + </auth> + <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2'> + <host name='172.24.193.62' port='6789'/> + <host name='172.24.193.63' port='6789'/> + <host name='172.24.193.64' port='6789'/> + </source> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </disk> + +======================== +[root@ceph-client ceph]# cat /run/libvirt/qemu/c7_ceph.xml + + +<domstatus state='running' reason='booted' pid='57437'> + <monitor path='/var/lib/libvirt/qemu/domain-19-c7_ceph/monitor.sock' json='1' type='unix'/> + <namespaces> + <mount/> + </namespaces> + <vcpus> + <vcpu id='0' pid='57487'/> + <vcpu id='1' pid='57488'/> + </vcpus> + <qemuCaps> + <flag name='kvm'/> + <flag name='no-hpet'/> + <flag name='spice'/> + <flag name='boot-index'/> + <flag name='hda-duplex'/> + <flag name='ccid-emulated'/> + <flag name='ccid-passthru'/> + <flag name='virtio-tx-alg'/> + <flag name='virtio-blk-pci.ioeventfd'/> + <flag name='sga'/> + <flag name='virtio-blk-pci.event_idx'/> + <flag name='virtio-net-pci.event_idx'/> + <flag name='piix3-usb-uhci'/> + <flag name='piix4-usb-uhci'/> + <flag name='usb-ehci'/> + <flag name='ich9-usb-ehci1'/> + <flag name='vt82c686b-usb-uhci'/> + <flag name='pci-ohci'/> + <flag name='usb-redir'/> + <flag name='usb-hub'/> + <flag name='ich9-ahci'/> + <flag name='no-acpi'/> + <flag name='virtio-blk-pci.scsi'/> + <flag name='scsi-disk.channel'/> + <flag name='scsi-block'/> + <flag name='transaction'/> + <flag name='block-job-async'/> + <flag name='scsi-cd'/> + <flag name='ide-cd'/> + <flag name='hda-micro'/> + <flag name='dump-guest-memory'/> + <flag name='nec-usb-xhci'/> + <flag name='balloon-event'/> + <flag name='lsi'/> + <flag name='virtio-scsi-pci'/> + <flag name='blockio'/> + <flag name='disable-s3'/> + <flag name='disable-s4'/> + <flag name='usb-redir.filter'/> + <flag name='ide-drive.wwn'/> + <flag name='scsi-disk.wwn'/> + <flag name='seccomp-sandbox'/> + <flag name='reboot-timeout'/> + <flag name='seamless-migration'/> + <flag name='block-commit'/> + <flag name='vnc'/> + <flag name='drive-mirror'/> + <flag name='usb-redir.bootindex'/> + <flag name='usb-host.bootindex'/> + <flag name='blockdev-snapshot-sync'/> + <flag name='qxl'/> + <flag name='VGA'/> + <flag name='cirrus-vga'/> + <flag name='vmware-svga'/> + <flag name='device-video-primary'/> + <flag name='usb-serial'/> + <flag name='usb-net'/> + <flag name='add-fd'/> + <flag name='nbd-server'/> + <flag name='virtio-rng'/> + <flag name='rng-random'/> + <flag name='rng-egd'/> + <flag name='megasas'/> + <flag name='tpm-passthrough'/> + <flag name='tpm-tis'/> + <flag name='pci-bridge'/> + <flag name='vfio-pci'/> + <flag name='vfio-pci.bootindex'/> + <flag name='scsi-generic'/> + <flag name='scsi-generic.bootindex'/> + <flag name='mem-merge'/> + <flag name='vnc-websocket'/> + <flag name='drive-discard'/> + <flag name='mlock'/> + <flag name='device-del-event'/> + <flag name='dmi-to-pci-bridge'/> + <flag name='i440fx-pci-hole64-size'/> + <flag name='q35-pci-hole64-size'/> + <flag name='usb-storage'/> + <flag name='usb-storage.removable'/> + <flag name='ich9-intel-hda'/> + <flag name='kvm-pit-lost-tick-policy'/> + <flag name='boot-strict'/> + <flag name='pvpanic'/> + <flag name='spice-file-xfer-disable'/> + <flag name='spiceport'/> + <flag name='usb-kbd'/> + <flag name='msg-timestamp'/> + <flag name='active-commit'/> + <flag name='change-backing-file'/> + <flag name='memory-backend-ram'/> + <flag name='numa'/> + <flag name='memory-backend-file'/> + <flag name='usb-audio'/> + <flag name='rtc-reset-reinjection'/> + <flag name='splash-timeout'/> + <flag name='iothread'/> + <flag name='migrate-rdma'/> + <flag name='ivshmem'/> + <flag name='drive-iotune-max'/> + <flag name='VGA.vgamem_mb'/> + <flag name='vmware-svga.vgamem_mb'/> + <flag name='qxl.vgamem_mb'/> + <flag name='pc-dimm'/> + <flag name='machine-vmport-opt'/> + <flag name='aes-key-wrap'/> + <flag name='dea-key-wrap'/> + <flag name='pci-serial'/> + <flag name='vhost-user-multiqueue'/> + <flag name='migration-event'/> + <flag name='ioh3420'/> + <flag name='x3130-upstream'/> + <flag name='xio3130-downstream'/> + <flag name='rtl8139'/> + <flag name='e1000'/> + <flag name='virtio-net'/> + <flag name='gic-version'/> + <flag name='incoming-defer'/> + <flag name='virtio-gpu'/> + <flag name='virtio-keyboard'/> + <flag name='virtio-mouse'/> + <flag name='virtio-tablet'/> + <flag name='virtio-input-host'/> + <flag name='chardev-file-append'/> + <flag name='ich9-disable-s3'/> + <flag name='ich9-disable-s4'/> + <flag name='vserport-change-event'/> + <flag name='virtio-balloon-pci.deflate-on-oom'/> + <flag name='mptsas1068'/> + <flag name='qxl.vram64_size_mb'/> + <flag name='chardev-logfile'/> + <flag name='debug-threads'/> + <flag name='secret'/> + <flag name='pxb'/> + <flag name='pxb-pcie'/> + <flag name='device-tray-moved-event'/> + <flag name='nec-usb-xhci-ports'/> + <flag name='virtio-scsi-pci.iothread'/> + <flag name='name-guest'/> + <flag name='qxl.max_outputs'/> + <flag name='spice-unix'/> + <flag name='drive-detect-zeroes'/> + <flag name='tls-creds-x509'/> + <flag name='intel-iommu'/> + <flag name='smm'/> + <flag name='virtio-pci-disable-legacy'/> + <flag name='query-hotpluggable-cpus'/> + <flag name='virtio-net.rx_queue_size'/> + <flag name='virtio-vga'/> + <flag name='drive-iotune-max-length'/> + <flag name='ivshmem-plain'/> + <flag name='ivshmem-doorbell'/> + <flag name='query-qmp-schema'/> + <flag name='gluster.debug_level'/> + <flag name='drive-iotune-group'/> + <flag name='query-cpu-model-expansion'/> + <flag name='virtio-net.host_mtu'/> + <flag name='nvdimm'/> + <flag name='pcie-root-port'/> + <flag name='query-cpu-definitions'/> + <flag name='block-write-threshold'/> + <flag name='query-named-block-nodes'/> + <flag name='cpu-cache'/> + <flag name='qemu-xhci'/> + <flag name='kernel-irqchip'/> + <flag name='kernel-irqchip.split'/> + <flag name='intel-iommu.intremap'/> + <flag name='intel-iommu.caching-mode'/> + <flag name='intel-iommu.eim'/> + <flag name='intel-iommu.device-iotlb'/> + <flag name='virtio.iommu_platform'/> + <flag name='virtio.ats'/> + <flag name='loadparm'/> + <flag name='vnc-multi-servers'/> + <flag name='virtio-net.tx_queue_size'/> + <flag name='chardev-reconnect'/> + <flag name='virtio-gpu.max_outputs'/> + <flag name='vxhs'/> + <flag name='virtio-blk.num-queues'/> + <flag name='vmcoreinfo'/> + <flag name='numa.dist'/> + <flag name='disk-share-rw'/> + <flag name='iscsi.password-secret'/> + <flag name='isa-serial'/> + <flag name='dump-completed'/> + <flag name='qcow2-luks'/> + <flag name='pcie-pci-bridge'/> + <flag name='seccomp-blacklist'/> + <flag name='query-cpus-fast'/> + <flag name='disk-write-cache'/> + <flag name='nbd-tls'/> + <flag name='tpm-crb'/> + <flag name='pr-manager-helper'/> + <flag name='qom-list-properties'/> + <flag name='memory-backend-file.discard-data'/> + <flag name='sdl-gl'/> + <flag name='screendump_device'/> + <flag name='hda-output'/> + <flag name='blockdev-del'/> + <flag name='vmgenid'/> + <flag name='vhost-vsock'/> + <flag name='chardev-fd-pass'/> + <flag name='tpm-emulator'/> + <flag name='mch'/> + <flag name='mch.extended-tseg-mbytes'/> + <flag name='usb-storage.werror'/> + <flag name='egl-headless'/> + <flag name='vfio-pci.display'/> + </qemuCaps> + <devices> + <device alias='rng0'/> + <device alias='virtio-disk0'/> + <device alias='virtio-serial0'/> + <device alias='video0'/> + <device alias='serial0'/> + <device alias='balloon0'/> + <device alias='channel0'/> + <device alias='net0'/> + <device alias='input0'/> + <device alias='scsi0'/> + <device alias='usb'/> + </devices> + <libDir path='/var/lib/libvirt/qemu/domain-19-c7_ceph'/> + <channelTargetDir path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph'/> + <cpu mode='custom' match='exact' check='partial'> + <model fallback='forbid'>Broadwell</model> + </cpu> + <chardevStdioLogd/> + <allowReboot value='yes'/> + <blockjobs active='no'/> + <domain type='kvm' id='19'> + <name>c7_ceph</name> + <uuid>ff08671e-824c-4939-80ec-602235c0662e</uuid> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Broadwell</model> + <feature policy='require' name='vme'/> + <feature policy='require' name='f16c'/> + <feature policy='require' name='rdrand'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + <feature policy='disable' name='erms'/> + <feature policy='require' name='xsaveopt'/> + <feature policy='require' name='abm'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator> + <disk type='network' device='disk'> + <driver name='qemu' type='raw' cache='writeback'/> + <auth username='libvirt'> + <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/> + </auth> + <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2' tlsFromConfig='0'> + <host name='172.24.193.62' port='6789'/> + <host name='172.24.193.63' port='6789'/> + <host name='172.24.193.64' port='6789'/> + <privateData> + <objects> + <secret type='auth' alias='virtio-disk0-secret0'/> + </objects> + </privateData> + </source> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <alias name='usb'/> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <alias name='usb'/> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <alias name='usb'/> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='scsi' index='0' model='lsilogic'> + <alias name='scsi0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:2e:e1:1f'/> + <source bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/2'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/2'> + <source path='/dev/pts/2'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'> + <listen type='address' address='0.0.0.0' fromConfig='0' autoGenerated='no'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </rng> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c99,c659</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c99,c659</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> + </domain> +</domstatus> +[root@ceph-client ceph]# + +/usr/local/qemu-3.0/bin/qemu-system-x86_64 which is build by qemu-3.0 source code , first i build qemu-3.0 source with --enable-rbd , +later i rebuild qemu-3.0 source with more config paramter from centos7-2009 qemu, those config paramter from qemu-kvm-1.5.3-175.el7.src.rpm ,which has those paramters: +# QEMU configure log Fri Mar 3 18:22:31 CST 2023 +# Configured with: './configure' '--prefix=/usr' '--libdir=/usr/lib64' '--sysconfdir=/etc' '--interp-prefix=/usr/qemu-%M' '--audio-drv-list=pa,alsa' '--with-confsuffix=/qemu-kvm' '--localstatedir=/var' '--libexecdir=/usr/libexec' '--wit +h-pkgversion=qemu-kvm-1.5.3-175.el7' '--disable-strip' '--disable-qom-cast-debug' '--extra-ldflags=-Wl,--build-id -pie -Wl,-z,relro -Wl,-z,now' '--extra-cflags=-O2 -g -pipe -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer +-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIE -DPIE' '--enable-trace-backend=dtrace' '--enable-werror' '--disable-xen' '--disable-virtfs' '--enable-kvm' '--enable-libusb' '--enable-spice' '--enable-seccomp' '--disable-fdt' '-- +enable-docs' '--disable-sdl' '--disable-debug-tcg' '--disable-sparse' '--disable-brlapi' '--disable-bluez' '--disable-vde' '--disable-curses' '--enable-curl' '--enable-libssh2' '--enable-vnc-tls' '--enable-vnc-sasl' '--enable-linux-aio' + '--enable-smartcard-nss' '--enable-lzo' '--enable-snappy' '--enable-usb-redir' '--enable-vnc-png' '--disable-vnc-jpeg' '--enable-vnc-ws' '--enable-uuid' '--disable-vhost-scsi' '--disable-guest-agent' '--disable-live-block-ops' '--disab +le-live-block-migration' '--enable-rbd' '--enable-glusterfs' '--enable-tcmalloc' '--block-drv-rw-whitelist=qcow2,raw,file,host_device,blkdebug,nbd,iscsi,gluster,rbd' '--block-drv-ro-whitelist=vmdk,vhdx,vpc,ssh,https' '--iasl=/bin/false' + '--target-list=x86_64-softmmu' + + +, after rebuild the qemu-system-x86_64 : + +virsh start c7_ceph +[root@ceph-client ceph]# virsh list --all + Id Name State +---------------------------------------------------- + 19 c7_ceph running + +qemu still stuck at booting from hard disk... + + + +to my surprised if the libvirtd xml file if i replace /usr/local/qemu-3.0/bin/qemu-system-x86_64 with /usr/libexec/bin/qemu-kvm , then the vm +can start successfully . diff --git a/results/classifier/108/other/1533141 b/results/classifier/108/other/1533141 new file mode 100644 index 000000000..d0cd7d1fb --- /dev/null +++ b/results/classifier/108/other/1533141 @@ -0,0 +1,43 @@ +device: 0.696 +graphic: 0.646 +PID: 0.615 +semantic: 0.598 +vnc: 0.588 +network: 0.580 +socket: 0.570 +other: 0.547 +files: 0.507 +performance: 0.469 +boot: 0.442 +permissions: 0.266 +KVM: 0.256 +debug: 0.241 + +qemu/disas/libvixl/vixl/invalset.h: 2 * sanity check after use ? + +1. + +[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check. + + while (!IsValid(elements[low]) && (low < high)) ++low; + +2. + +[qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check. + + while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle; + +Also, binary search is a standard C library routine. Suggest use. + +libvixl is not part of QEMU proper, but is an upstream library which we use (as documented in disas/libvixl/README). If you want to suggest coding style changes to it I would recommend reporting them to the upstream project: https://github.com/armvixl/vixl . + +QEMU just takes the most recent release of the library and includes it in our repo without making any changes to the code if we can avoid it. + + + +>If you want to suggest coding style changes to it I would recommend reporting them to the upstream project: + +Thanks. Done here: + +https://github.com/armvixl/vixl/issues + diff --git a/results/classifier/108/other/1533848 b/results/classifier/108/other/1533848 new file mode 100644 index 000000000..9e5ac2bd5 --- /dev/null +++ b/results/classifier/108/other/1533848 @@ -0,0 +1,21 @@ +device: 0.821 +semantic: 0.635 +socket: 0.559 +network: 0.511 +other: 0.440 +boot: 0.417 +vnc: 0.415 +permissions: 0.372 +graphic: 0.369 +debug: 0.327 +files: 0.311 +performance: 0.281 +PID: 0.118 +KVM: 0.078 + +A workaround for Windows 7 ACPI SLIC table behavior when used with OVMF + +When OVMF is used, Windows 7 refuses to read SLIC ACPI table, passed via -acpitable option, because it expects oem id and oem table id to match in SLIC, XSDT, RSDT, FADT. There's a detailed discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1248758 + +Fixed in 37ad223^..ae12374. + diff --git a/results/classifier/108/other/1534 b/results/classifier/108/other/1534 new file mode 100644 index 000000000..95cdfb4fa --- /dev/null +++ b/results/classifier/108/other/1534 @@ -0,0 +1,16 @@ +permissions: 0.613 +semantic: 0.305 +device: 0.262 +graphic: 0.248 +boot: 0.218 +performance: 0.217 +KVM: 0.183 +vnc: 0.161 +PID: 0.107 +network: 0.097 +other: 0.064 +debug: 0.036 +socket: 0.025 +files: 0.019 + +usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid) diff --git a/results/classifier/108/other/1534382 b/results/classifier/108/other/1534382 new file mode 100644 index 000000000..a5dca3421 --- /dev/null +++ b/results/classifier/108/other/1534382 @@ -0,0 +1,46 @@ +graphic: 0.887 +performance: 0.726 +device: 0.705 +other: 0.651 +semantic: 0.648 +permissions: 0.564 +socket: 0.543 +network: 0.523 +boot: 0.482 +PID: 0.424 +files: 0.409 +vnc: 0.408 +debug: 0.363 +KVM: 0.345 + +loadvm makes Windows 7 x86 guest crash with some CPUs + +Running qemu with kvm enabled and -cpu set to some of the more "modern" CPUs, +and having Windows 7 x86 as the guest. + +After guest OS loads, start some app (I started "cmd"), then do "savevm". +After that, do some more activity (I closed cmd window and opened IE), +then do "loadvm" of the previously saved snapshot. + +loadvm shows briefly the state that the system was in at the snapshot time, +then guest OS crashes (blue screen). + +Originally I saw this problem on qemu 1.4.0, +then I also tried qemu 2.5.0 and found the same problem. + +The CPUs that I tried were mostly those that support NX bit (core2duo, +qemu64, kvm64, Nehalem, etc.) + +If I use the default CPU, or some other like qemu32/kvm32, +the problem does not occur. + +What is your host processor? + +it is Intel(R) Xeon(R) CPU E5-1410 0 @ 2.80GHz + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1534978 b/results/classifier/108/other/1534978 new file mode 100644 index 000000000..dd5238677 --- /dev/null +++ b/results/classifier/108/other/1534978 @@ -0,0 +1,41 @@ +files: 0.881 +boot: 0.868 +device: 0.777 +graphic: 0.680 +performance: 0.668 +socket: 0.629 +semantic: 0.613 +permissions: 0.589 +vnc: 0.581 +network: 0.563 +other: 0.549 +PID: 0.457 +debug: 0.456 +KVM: 0.391 + +Windows command line -name cannot use = sign + +Windows command line: + +qemu.exe -L . -name "32-bit Emulation Session RAM=500MB" -boot c -m 500 -drive file=\\.\PhysicalDrive2 + +This fails to run. +If I remove the = sign in the -name quoted string it runs OK. + +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. + + +Cannot reproduce in recent version - please close. + +Thanks for checking! Closing now. + diff --git a/results/classifier/108/other/1535497 b/results/classifier/108/other/1535497 new file mode 100644 index 000000000..134c3bedc --- /dev/null +++ b/results/classifier/108/other/1535497 @@ -0,0 +1,44 @@ +device: 0.774 +performance: 0.741 +network: 0.734 +KVM: 0.694 +graphic: 0.691 +permissions: 0.634 +boot: 0.605 +vnc: 0.524 +semantic: 0.481 +socket: 0.438 +files: 0.326 +PID: 0.230 +other: 0.147 +debug: 0.076 + +Guest can not boot up when assigned more than 20 vcpus with option "-no-acpi" + +Environment: + ------------------------------- + KVM commit/branch: da3f7ca3/next + Qemu commit/branch: 7b8a354d/master + Host OS: RHEL7.2 ia32e + Host Kernel: 4.4-rc2 + Guest OS: RHEL7.2 ia32e + +Description: + -------------------------------- +When assign more than 20 vpcus with option "-no-acpi", guest can not boot up. + +Reproduce: + ---------------- + 1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + + +Bisect show the bad commit is 9ee2e2625 of seabios. + + + + + +Can you still reproduce this issue with the latest version of QEMU? If this is a bug in seabios, have you tried to report this to seabios instead? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1536487 b/results/classifier/108/other/1536487 new file mode 100644 index 000000000..ba4848cc9 --- /dev/null +++ b/results/classifier/108/other/1536487 @@ -0,0 +1,101 @@ +device: 0.905 +other: 0.898 +PID: 0.829 +KVM: 0.826 +semantic: 0.812 +graphic: 0.780 +performance: 0.758 +permissions: 0.739 +boot: 0.679 +socket: 0.665 +debug: 0.664 +files: 0.650 +network: 0.629 +vnc: 0.621 + +Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1 + +When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out: + + qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg' + +This appears to be related to the addition of a DMA interface to fw_cfg last October: + + http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04568.html + +"info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled: + + bus: main-system-bus + type System + ... + dev: fw_cfg_io, id "" + iobase = 1296 (0x510) + dma_iobase = 1300 (0x514) + dma_enabled = true + +Incidentally, this guest had just undergone a migration from QEMU 2.4.0 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration. + +It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher. + +Hi, +Proxmox users have reported same bug (qemu 2.5 with pc-i440fc-2.4 not migrating to qemu 2.4.1) + +https://forum.proxmox.com/threads/cant-live-migrate-after-dist-upgrade.26097/ + +I don't have verified yet, but it seem to be related. + + +http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042 + +sent a patch: http://thread.gmane.org/gmane.comp.emulators.qemu/395014 + +Fix committed in e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Note: Also affects Migration Xenial->Trusty (tested and ran into the same issue, that was how I found the bug) and very likely also Yakkety->Trusty. + + qemu | 2.0.0+dfsg-2ubuntu1.27 | trusty-security | source + qemu | 1:2.5+dfsg-5ubuntu10.4 | xenial-updates | source + +Subscribing server Team to look at this in the scope of the qemu packaging SRU work for Xenial. + +Migrating a VM from xenial -> trusty (or anything moving backward) is +not supported. + + +Hi Serge I agree to "created on xenial -> migrating to trusty" not being supported. +I already tended to even say "created on xenial with the Trusty machine type -> migrating to trusty" is not supported as well (at least it is failing for all combos I tried. + +But I wonder how far "anything moving backward" should go. + +Especially I found that the "created on Trusty, migrated to xenial (works), but later migrated back to trusty (fails)" seems affected by it as well. +I'd have thought that this would be supported. What is you opinion on this more specific case? + +You might ask on #virt for the opinion there, but I don't believe +migrating backward is supported in any case. t->x->t doesn't change +the fact that there is x->t. + + +> Especially I found that the "created on Trusty, migrated to xenial +> (works), but later migrated back to trusty (fails)" seems affected by +> it as well. + +The first migration of the t->x->t sequence does not really matter (if +anything it could introduce _more_ bugs!), so if x->t is not supported +then neither is t->x->t. + +The upstream QEMU project doesn't have the manpower to test and support +backwards migration. We try not to break it, and in this case there +was an easy fix and we suggest that Canonical backports it. However, +in general it's not guaranteed to work. + +The fix is commit e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a. + +Serge, Paulo - thank you both! + +I already had the patch but I think it was good to discuss and list the expected behavior not only for me, but for whoever else that comes by this or a similar case. + +I backported this and tried my tests again, but this alone isn't sufficient to get the T->X->T working (which is effectively 2.0->2.5->2.0). +Wily (2.4) is already out of service, so setting this to won't fix. + +Thanks for your guidance, but that now properly known I'll set the Xenial task to won't fix for now. + diff --git a/results/classifier/108/other/1538 b/results/classifier/108/other/1538 new file mode 100644 index 000000000..1f369e841 --- /dev/null +++ b/results/classifier/108/other/1538 @@ -0,0 +1,16 @@ +device: 0.852 +network: 0.613 +files: 0.554 +other: 0.550 +performance: 0.480 +debug: 0.468 +PID: 0.465 +graphic: 0.425 +vnc: 0.361 +permissions: 0.356 +socket: 0.349 +semantic: 0.323 +boot: 0.281 +KVM: 0.126 + +igd.c gives up IGD legacy mode if no option ROM found diff --git a/results/classifier/108/other/1538541 b/results/classifier/108/other/1538541 new file mode 100644 index 000000000..7fb928992 --- /dev/null +++ b/results/classifier/108/other/1538541 @@ -0,0 +1,80 @@ +graphic: 0.901 +other: 0.892 +KVM: 0.890 +vnc: 0.888 +semantic: 0.880 +debug: 0.874 +PID: 0.848 +performance: 0.832 +permissions: 0.819 +device: 0.811 +network: 0.796 +socket: 0.780 +boot: 0.740 +files: 0.686 + +qcow2 rejects request to use preallocation with backing file + +The 'preallocation=full' option to qemu-img / qcow2 block driver instructs QEMU to fully allocate the host file to the maximum size needed by the logical disk size. + +$ qemu-img create -f qcow2 -o preallocation=full base.qcow2 200M +Formatting 'base.qcow2', fmt=qcow2 size=209715200 encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 + +$ ls -alhs base.qcow2 +201M -rw-r--r--. 1 berrange berrange 201M Jan 27 12:49 base.qcow2 + + +When specifying a backing file for the qcow2 file, however, it rejects the preallocation request + +$ qemu-img create -f qcow2 -o preallocation=full,backing_file=base.qcow2 front.qcow2 200M +Formatting 'front.qcow2', fmt=qcow2 size=209715200 backing_file='base.qcow2' encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16 +qemu-img: front.qcow2: Backing file and preallocation cannot be used at the same time + + +It might seem like requesting full preallocation is redundant because most data associated with the image will be present in the backing file, as so the top layer is unlikely to ever need the full preallocation. Rejecting this, however, means it is not (officially) possible to reserve disk space for the top layer to guarantee that future copy-on-writes will never get ENOSPC. + +OpenStack in particular uses backing files with all images, in order to avoid the I/O overhead of copying the backing file contents into the per-VM disk image. It, however, still wants to have a guarantee that the per-VM image will never hit an ENOSPC scenario. + +Currently it has to hack around QEMU's refusal to allow backing_file + preallocation, by calling 'fallocate' on the qcow2 file after it has been created. This is an inexact fix though, because it doesn't take account of fact that qcow2 metadata can takes some MBs of space. + +Thus, it would like to see preallocation=full supported in combination with backing files. + +Using any preallocation value other than none will result in all data clusters of the new image being used. That means that any I/O request will be served by that image, and never by the backing file. This is why preallocating an image with a backing file is not supported, because it generally doesn't make any sense. The backing file will never be seen anyway. + +In order to support this, qcow2 will need to support preallocated data clusters which are explicitly marked as empty (where "empty" is not "zero"; "empty" means "fall through to the backing file"). This has been proposed before, but has not been implemented so far. + +By the way, this is the very reason why explicitly forbidding the combination of backing file and preallocation is very reasonable: Right now, the backing file would be invisible, a preallocated image always returns zeros when read. With the above feature implemented, the backing file would be visible. In order to allow this change in behavior, we have to make the combination an error for now. + +Max + +PS: The reason I write this is so that you know that this is not a bug, but correct behavior in view of a missing feature (that should indeed be implemented). + +> In order to support this, qcow2 will need to support preallocated data clusters which are explicitly marked as empty (where "empty" is not "zero"; "empty" means "fall through to the backing file"). This has been proposed before, but has not been implemented so far. + +This sounds like a bit of extra work, but I'm puzzelled why we can't have a preallocation option which simply calls fallocate() to grow the file to the right size. From qcow2 pov, the extra clusters won't be allocated - we're just making sure the filesystem has reserved sufficient space for when qcow2 does later allocate the clusters during a copy-on-write. Perhaps this would imply a new option to the 'preallocation' option rather than 'full' + +The idea that qcow2 could just reserve enough space that it will never need any additional clusters stands on somewhat shaky ground anyway. You can count in metadata such as refcount tables/blocks and the L1/L2 table for an image with the full virtual disk size used. This doesn't cover things like snapshots or in the future bitmaps; I'm not completely sure, but it might also fail to cover some scenarios that involve discard and where some space isn't immediately reused due to image fragmentation. Whether or not a given static size is sufficient for an image depends primarily on how the image is going to be used. + +What you seem to want isn't really qcow2 preallocation (which would involve, as Max said, preallocating all clusters on the qcow2 level), but preallocation of the image file in the file system layer to a size that matches your use of qcow2. I'm afraid that doing this in the management layer, which actually knows best how it's going to use the image, makes more sense than letting qemu guess and implement a hack that preallocates only on the file system, but not the image format level. + +Preallocating the understanding image file at the management layer though means that the mgmt tool has to understand the full details of the qcow2 file format. The mgmt layer knows it created a 20 GB qcow2 file, but does not know that once you have stored 20 GB of user data in it, it will actually consume 20 GB + NNN MB extra. Calculating hat NNN MB extra is trivial for qemu since it knows the file format already, but hard for the mgmt app + +It is not exactly trivial, and it being in qemu does not make it simpler. http://git.qemu.org/?p=qemu.git;a=blob;f=block/qcow2.c;h=fd8436c5f8b13ab0e8c605147ce76e6b6a8e5f95;hb=HEAD#l2105 is the code that calculates the size; as you can see, it is pretty self-contained. + +Max + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1539 b/results/classifier/108/other/1539 new file mode 100644 index 000000000..73cc73a6e --- /dev/null +++ b/results/classifier/108/other/1539 @@ -0,0 +1,18 @@ +device: 0.887 +network: 0.606 +other: 0.562 +performance: 0.544 +socket: 0.467 +permissions: 0.427 +boot: 0.411 +semantic: 0.350 +graphic: 0.312 +files: 0.304 +vnc: 0.263 +debug: 0.227 +PID: 0.062 +KVM: 0.022 + +Support for SPC58NH92C5 +Additional information: + |