diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1192 | 150 | ||||
| -rw-r--r-- | results/classifier/108/other/1192065 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/1192344 | 41 | ||||
| -rw-r--r-- | results/classifier/108/other/1192464 | 58 | ||||
| -rw-r--r-- | results/classifier/108/other/1192499 | 474 | ||||
| -rw-r--r-- | results/classifier/108/other/1192780 | 181 |
6 files changed, 928 insertions, 0 deletions
diff --git a/results/classifier/108/other/1192 b/results/classifier/108/other/1192 new file mode 100644 index 00000000..44782840 --- /dev/null +++ b/results/classifier/108/other/1192 @@ -0,0 +1,150 @@ +other: 0.919 +permissions: 0.910 +debug: 0.907 +graphic: 0.905 +device: 0.899 +PID: 0.897 +boot: 0.895 +semantic: 0.895 +socket: 0.891 +files: 0.890 +network: 0.879 +performance: 0.878 +vnc: 0.878 +KVM: 0.866 + +Abort in xhci_find_stream() +Description of problem: +I triggered an abort in xhci_find_stream() [1]. This is because the +secondary stream arrays is enabled by setting linear stream array (LSA) bit (in +endpoint context) to 0. We may show warnings and drop this operation. + +``` c +static XHCIStreamContext *xhci_find_stream(XHCIEPContext *epctx, + unsigned int streamid, + uint32_t *cc_error) +{ + // ... + if (epctx->lsa) { + // ... + } else { + FIXME("secondary streams not implemented yet"); // <----------- [1] + } + // ... +``` +Steps to reproduce: +Step 1: download the prepared rootfs and the image. + +https://drive.google.com/file/d/10C2110VH-GrwACiPebC8-Vgcf5_Ny8Sd/view?usp=sharing +https://drive.google.com/file/d/1jAMf8rtTM8p88gamhNk4HC5Z34XtjUHw/view?usp=sharing + +Step 2: run the following script. + +``` bash +QEMU_PATH=../../../qemu/build/qemu-system-x86_64 +KERNEL_PATH=./bzImage +ROOTFS_PATH=./rootfs.ext2 +$QEMU_PATH \ + -M q35 -m 1G \ + -kernel $KERNEL_PATH \ + -drive file=$ROOTFS_PATH,if=virtio,format=raw \ + -append "root=/dev/vda console=ttyS0" \ + -net nic,model=virtio -net user \ + -drive file=null-co://,if=none,format=raw,id=disk0 \ + -device qemu-xhci,id=xhci -device usb-storage,drive=disk0 \ + -device usb-bot -device usb-tablet,bus=xhci.0 \ + -chardev null,id=cd0 -chardev null,id=cd1 \ + -device usb-braille,chardev=cd0 -device usb-ccid -device usb-ccid \ + -device usb-kbd -device usb-mouse -device usb-serial,chardev=cd1 \ + -device usb-tablet -device usb-wacom-tablet -device usb-audio \ + -nographic +``` + +Step 3: with spawned shell (the user is root and the password is empty), run +`xhci-00`. +Additional information: +``` +root@5b4fda3ee725:~/videzzo/videzzo_qemu/out-san# DEFAULT_INPUT_MAXSIZE=10000000 /root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci -max_len=10000000 -detect_leaks=0 poc-qemu-videzzo-i386-target-videzzo-fuzz-xhci-crash-4a11736abb111efe4b29a6931f403561f9a0f9ec +==71545==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55e05e05e640). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 2668437424 +INFO: Loaded 1 modules (423456 inline 8-bit counters): 423456 [0x55e0606e8000, 0x55e06074f620), +INFO: Loaded 1 PC tables (423456 PCs): 423456 [0x55e060071ae0,0x55e0606e7ce0), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *capabilities*, *operational*, *runtime*, *doorbell*, *usb3 port* +This process will fuzz the following MemoryRegions: + * usb3 port #1[0] (size 10) + * usb3 port #4[0] (size 10) + * capabilities[0] (size 40) + * usb3 port #3[0] (size 10) + * operational[0] (size 400) + * usb3 port #2[0] (size 10) + * runtime[0] (size 220) + * doorbell[0] (size 820) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * capabilities, EVENT_TYPE_MMIO_READ, 0xe0000000 +0x40, 4,4 + * capabilities, EVENT_TYPE_MMIO_WRITE, 0xe0000000 +0x40, 4,4 + * operational, EVENT_TYPE_MMIO_READ, 0xe0000040 +0x400, 4,8 + * operational, EVENT_TYPE_MMIO_WRITE, 0xe0000040 +0x400, 4,8 + * runtime, EVENT_TYPE_MMIO_READ, 0xe0001000 +0x220, 4,8 + * runtime, EVENT_TYPE_MMIO_WRITE, 0xe0001000 +0x220, 4,8 + * doorbell, EVENT_TYPE_MMIO_READ, 0xe0002000 +0x820, 4,4 + * doorbell, EVENT_TYPE_MMIO_WRITE, 0xe0002000 +0x820, 4,4 + * usb3 port #4, EVENT_TYPE_MMIO_READ, 0xe0000470 +0x10, 4,4 + * usb3 port #4, EVENT_TYPE_MMIO_WRITE, 0xe0000470 +0x10, 4,4 + * usb3 port #1, EVENT_TYPE_MMIO_READ, 0xe0000440 +0x10, 4,4 + * usb3 port #1, EVENT_TYPE_MMIO_WRITE, 0xe0000440 +0x10, 4,4 + * usb3 port #2, EVENT_TYPE_MMIO_READ, 0xe0000450 +0x10, 4,4 + * usb3 port #2, EVENT_TYPE_MMIO_WRITE, 0xe0000450 +0x10, 4,4 + * usb3 port #3, EVENT_TYPE_MMIO_READ, 0xe0000460 +0x10, 4,4 + * usb3 port #3, EVENT_TYPE_MMIO_WRITE, 0xe0000460 +0x10, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 197Mb +Running: poc-qemu-videzzo-i386-target-videzzo-fuzz-xhci-crash-4a11736abb111efe4b29a6931f403561f9a0f9ec +../hw/usb/hcd-xhci.c:1099:25: runtime error: shift exponent 156 is too large for 32-bit type 'int' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/usb/hcd-xhci.c:1099:25 in +FIXME xhci_find_stream:998 secondary streams not implemented yet +==71545== ERROR: libFuzzer: deadly signal + #0 0x55e05a7f874e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55e05a7473c1 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55e05a720c06 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:235:18 + #3 0x55e05a720cd2 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:1 + #4 0x55e05a720cd2 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:206:19 + #5 0x7fa0b025c41f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fa0b006e00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fa0b006e00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fa0b004d858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x55e05a828c9a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x55e05bd528c3 in xhci_find_stream /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:998:9 + #11 0x55e05bd46ca5 in xhci_kick_epctx /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:1922:17 + #12 0x55e05bd7d7ff in xhci_kick_ep /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:1838:5 + #13 0x55e05bd94ab9 in xhci_doorbell_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/usb/hcd-xhci.c:3163:13 + #14 0x55e05cfed443 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #15 0x55e05cfecd81 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #16 0x55e05cfeb68c in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #17 0x55e05d0760be in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #18 0x55e05d06443b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #19 0x55e05d063ef8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #20 0x55e05a83813b in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1072:5 + #21 0x55e05a8365b5 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1197:28 + #22 0x55e05e059fff in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #23 0x55e05e05137b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #24 0x55e05e051250 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #25 0x55e05a83f17c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1472:12 + #26 0x55e05e05e8e2 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #27 0x55e05a72173d in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:589:17 + #28 0x55e05a7044c4 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x55e05a70f43e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:882:19 + #30 0x55e05a6fba46 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7fa0b004f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x55e05a6fba9d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-i386-target-videzzo-fuzz-xhci+0x265aa9d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/108/other/1192065 b/results/classifier/108/other/1192065 new file mode 100644 index 00000000..ebc00b23 --- /dev/null +++ b/results/classifier/108/other/1192065 @@ -0,0 +1,24 @@ +performance: 0.770 +graphic: 0.760 +device: 0.732 +other: 0.722 +semantic: 0.667 +PID: 0.505 +boot: 0.489 +vnc: 0.469 +network: 0.462 +permissions: 0.456 +socket: 0.441 +debug: 0.436 +files: 0.334 +KVM: 0.306 + +qemu release memory to system + +Qemu pre-allocates the maximum balloon amount which is inconvinient if all of the memory is used up and some other system needs to be added memory resource + +eg:- I have 4GB RAM with 4 virtual systems to be run. +I want each of them to start with 1GB RAM with maximum 2GB possible. This is not achievable since qemu pre-allocates the maximum balloon amount which is 2GBx4 systems . So to start all 4 systems the system needs 8GB RAM rather than 4GB RAM to start with although I have told initial balloon amount to be 1GB. + +Looking through old bug tickets... I think you should rather use hotpluggable memory here for the guests instead - or use a big swap partition on the host. Anyway, this is not a bug, so closing this ticket now. + diff --git a/results/classifier/108/other/1192344 b/results/classifier/108/other/1192344 new file mode 100644 index 00000000..1ce54cd1 --- /dev/null +++ b/results/classifier/108/other/1192344 @@ -0,0 +1,41 @@ +graphic: 0.818 +performance: 0.697 +device: 0.684 +socket: 0.580 +other: 0.568 +PID: 0.531 +files: 0.522 +network: 0.517 +semantic: 0.515 +boot: 0.513 +vnc: 0.501 +debug: 0.360 +permissions: 0.358 +KVM: 0.190 + +qemu crashes on unaligned extended disk reads + +When performing a BIOS extended disk read (INT 13H, AH=0x42), if the offset of the buffer destination in the DAP (disk address packet) is not dword-aligned (i.e. a multiple of 4), SeaBIOS attempts to execute code at non-mapped address 0xb4f53, causing QEMU to crash. I imagine it's a bug in the BIOS code, but it does cause QEMU to crash. + +QEMU version: 1.4.0 (Debian 1.4.0+dfsg-1expubuntu4) (from Ubuntu repository) +SeaBIOS version: 1.7.2-20130119_170942-roseapple +command line: qemu-system-x86_64 -m 64 -hda hda.img -monitor stdio +CPU: Intel Core i7 CPU M620 on a Dell Latitude E6410 +OS: Ubuntu, GNU/Linux 3.8.0-25-generic, 64-bit + +On Tue, Jun 18, 2013 at 09:23:31PM -0000, Andrew McGowen wrote: +> When performing a BIOS extended disk read (INT 13H, AH=0x42), if the +> offset of the buffer destination in the DAP (disk address packet) is not +> dword-aligned (i.e. a multiple of 4), SeaBIOS attempts to execute code +> at non-mapped address 0xb4f53, causing QEMU to crash. I imagine it's a +> bug in the BIOS code, but it does cause QEMU to crash. + +Can you post details on the "crash"? What is the error message? + +Stefan + + +...well this is embarrassing - it was an issue with my code not saving/restoring registers on the stack properly. + +Marking this ticket as "Invalid" according to comment #2. + diff --git a/results/classifier/108/other/1192464 b/results/classifier/108/other/1192464 new file mode 100644 index 00000000..450eb4cb --- /dev/null +++ b/results/classifier/108/other/1192464 @@ -0,0 +1,58 @@ +debug: 0.834 +network: 0.810 +performance: 0.792 +graphic: 0.767 +device: 0.713 +other: 0.691 +semantic: 0.655 +PID: 0.655 +socket: 0.638 +vnc: 0.550 +boot: 0.314 +permissions: 0.314 +files: 0.295 +KVM: 0.231 + +udp checksum computed as 0 not converted to 0xffff, from guest os that share a common linux bridge among multiple guest os + +UDP checksum computed as '0' during transmission of packets that uses e1000 NIC in the Guest as well as emulated h/w in the qemu layer, That needs to be converted to 0xffff, This occurs only when Hardware checksum offload is been set in the guest OS NIC and made it as a transmitter. The guest O.S use the N/W interface that is been shared to the linux brige created in the host (used source=<bridge>) in the xml tags of libvirt. + +As per RFC768(http://tools.ietf.org/html/rfc768 [^]), If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care). + +Triaging old buck tickets ... can you still reproduce this issue with the latest version of QEMU? Is it only happening with e1000 or also with other NICs? What kind of network backend are you using (--netdev user ? tap ? ....). Could you please provide the full command line that you use to run QEMU? Thanks! + +Sorry, I meant "bug tickets", of course, not "buck tickets" ... need more coffee... + +Question is where is this zero checksum observed which is not clear from the report. + +If in the guest it is certainly correct. + +If in the host it is correct so long as the bridge appears to have checksum offloading as well. If whatever interface the guest packets appear to come from is not set up with checksum offloading this is a bug which should be fixed by setting the offload flags to match the guest. + +If outside the host this is a problem. + +Fixed: + +commit 0dacea92d26c31d453c58de2e99c178fee554166 +Author: Ed Swierk <email address hidden> +Date: Thu Nov 16 06:06:06 2017 -0800 + + net: Transmit zero UDP checksum as 0xFFFF + + The checksum algorithm used by IPv4, TCP and UDP allows a zero value + to be represented by either 0x0000 and 0xFFFF. But per RFC 768, a zero + UDP checksum must be transmitted as 0xFFFF because 0x0000 is a special + value meaning no checksum. + + Substitute 0xFFFF whenever a checksum is computed as zero when + modifying a UDP datagram header. Doing this on IPv4 and TCP checksums + is unnecessary but legal. Add a wrapper for net_checksum_finish() that + makes the substitution. + + (We can't just change net_checksum_finish(), as that function is also + used by receivers to verify checksums, and in that case the expected + value is always 0x0000.) + + Signed-off-by: Ed Swierk <email address hidden> + Signed-off-by: Jason Wang <email address hidden> + diff --git a/results/classifier/108/other/1192499 b/results/classifier/108/other/1192499 new file mode 100644 index 00000000..61fff209 --- /dev/null +++ b/results/classifier/108/other/1192499 @@ -0,0 +1,474 @@ +other: 0.942 +permissions: 0.941 +graphic: 0.939 +debug: 0.929 +performance: 0.926 +semantic: 0.925 +vnc: 0.920 +boot: 0.916 +KVM: 0.911 +device: 0.910 +network: 0.897 +PID: 0.895 +socket: 0.891 +files: 0.882 + +virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" + +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+0000: 4026: debug : virEventPollInterruptLocked:716 : Interrupting +2013-06-19 08:43:12.253+0000: 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'> + <name>VM1</name> + <uuid>47feb0e1-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_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</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='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' 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='0x0000' 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='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> + <seclabel type='none' model='selinux'/> +</domain> + + + +Thanks for submitting this bug. I can' t reproduce it with an empty image (sitting at cd boot menu). + +What is the underlying fs (/home/images) on both source and destination? + +Could you run 'apport-collect 1192499' on the destination host? + +Oh, actually I notice you have + +/usr/local/bin/qemu-system-x86_64 + +listed as the emulator in the .xml. That is not the qemu-system-x86_64 shipped with the qemu-system-x86 package. Does switching that for + + <emulator>/usr/bin/qemu-system-x86_64</emulator> + + +and see if that helps matters? + +We tried with <emulator>/usr/bin/qemu-system-x86_64</emulator> and we are facing the same issue. + +For both source and destination the fs is ext4. + +We are using fedora base, hence I have attached the sosreport of both source and destination. + + + +On 06/29/2013 12:15 AM, Serge Hallyn wrote: +> Thanks for submitting this bug. I can' t reproduce it with an empty +> image (sitting at cd boot menu). +> +> What is the underlying fs (/home/images) on both source and destination? + +For both source and destination the fs is ext4. + +> +> Could you run 'apport-collect 1192499' on the destination host? +We are using fedora base, hence I have attached the sosreport of both +source and destination in the bug. +> +> Oh, actually I notice you have +> +> /usr/local/bin/qemu-system-x86_64 +> +> listed as the emulator in the .xml. That is not the qemu-system-x86_64 +> shipped with the qemu-system-x86 package. Does switching that for +> +> <emulator>/usr/bin/qemu-system-x86_64</emulator> + +We tried with <emulator>/usr/bin/qemu-system-x86_64</emulator> and we +are facing the same issue. +> +> and see if that helps matters? +> +> ** Changed in: libvirt (Ubuntu) +> Status: New => Incomplete +> +Thanks, +Shastri + + + +Hi, + +I'm confused - what do you mean by you are using a fedora base? Are you talking about the VM, or the destination host? If the destination host, then (a) is it identical to the source host, and either way (b) exactly how did you set up the hosts with ubuntu packages? + +I am sorry. + +Host Kernel : 3.10.0-rc5+ [upstream kernel fedora base], both the source and destination host are the same. + +We test the upstream kernel, qemu and libvirt. We don't have ubuntu. + + +> I am sorry. +> +> Host Kernel : 3.10.0-rc5+ [upstream kernel fedora base], both the source +> and destination host are the same. +> +> We test the upstream kernel, qemu and libvirt. We don't have ubuntu. + +Oh, I see - then please see http://libvirt.org/bugs.html (specifically +"General libvirt bug reports") for where to file upstream bug reports. + + +Moving to qemu component as qemu is crashing based on the inputs from Michal Privoznik + +Bugzilla : Bug 979411 - virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" + + + + + + + + + + +The destination VM's log says: + + qemu: warning: error while loading state section id 1 + +This indicates that either there was an error on the destination while loading state or the migration stream got out of sync. + +Please check that QEMU on source and destination are identical. If you are running different versions of QEMU on source and destination this could be the cause. + +Try with qemu.git/master and a simple QEMU command-line (without libvirt): + + qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm -m 4000 \ + -drive file=/home/images/rhel64-64.qcow2,if=ide,format=qcow2,cache=none + +Use the same command-line on the destination but also add "-incoming tcp::1234". To start the migrate on the source, run "migrate -b tcp:<destination-ip>:1234" in the QEMU monitor. + +If the failure can be reproduce on qemu.git/master in this way it will be easier to debug. + +I will be away next week and therefore unable to look into this more. + +Thanks, I ll work on this and update it. + +On 07/05/2013 01:52 PM, Stefan Hajnoczi wrote: +> The destination VM's log says: +> +> qemu: warning: error while loading state section id 1 +> +> This indicates that either there was an error on the destination while +> loading state or the migration stream got out of sync. +> +> Please check that QEMU on source and destination are identical. If you +> are running different versions of QEMU on source and destination this +> could be the cause. +> +> Try with qemu.git/master and a simple QEMU command-line (without +> libvirt): +> +> qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm -m 4000 \ +> -drive file=/home/images/rhel64-64.qcow2,if=ide,format=qcow2,cache=none +> +> Use the same command-line on the destination but also add "-incoming +> tcp::1234". To start the migrate on the source, run "migrate -b tcp +> :<destination-ip>:1234" in the QEMU monitor. +I tried this "migrate -b tcp :<destination-ip>:1234" comes out and gives +me the qemu prompt [ I mean it doesn't wait till the migration +completes] and also on the destination the image is not growing, the +status shows paused. + +~Shastri +> +> If the failure can be reproduce on qemu.git/master in this way it will +> be easier to debug. +> +> I will be away next week and therefore unable to look into this more. +> + + + +> "migrate -b tcp :<destination-ip>:1234" + +There should be no space between tcp and the rest of the connection details: + +migrate -b tcp:<destination-ip>:1234 + +Is there still something left to do here, or could we close this ticket nowadays? + +There hasn't been a reply to my question in the last comment within +months, so I assume nobody cares about this anymore. So I'm closing this +ticket now... + +Created attachment 766573 +Source-migrate-logs + +Description of problem: + +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: + +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+0000: 4026: debug : virEventPollInterruptLocked:716 : Interrupting +2013-06-19 08:43:12.253+0000: 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'> + <name>VM1</name> + <uuid>47feb0e1-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_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</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='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' 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='0x0000' 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='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> + <seclabel type='none' model='selinux'/> +</domain> + +Can you provide the destination debug logs? Esp. content of /var/log/libvirt/qemu/VM1.log as there's supposed to be the reason why qemu died. + +Created attachment 766578 +Source Logs + +Created attachment 766579 +Destination Logs + +From the VM1_dest.log: + +... +Completed 97 % +Completed 98 % +Completed 99 % +qemu: warning: error while loading state section id 1 +load of migration failed + +So the qemu is unable to migrate itself. Therefore I think this is actually a qemu bug. +On the other hand, I wonder why the guest on the source is shut down. There's no sign of that in the logs. + +When the migration fails the guest gets shutdown on the source. + +[root@9 images]# virsh list --all + Id Name State +---------------------------------------------------- + 5 VM1 running + +[root@9 images]# virsh migrate --live rhel64-64 qemu+ssh:/IP/system tcp://IP --verbose --copy-storage-all + +Migration: [ 93 %]error: Unable to read from monitor: Connection reset by peer + + +At the destination: + +[root@9 images]# virsh list --all + Id Name State +---------------------------------------------------- + - VM1 shut off + +[root@destination]# virsh list --all + Id Name State +---------------------------------------------------- + 16 VM1 paused + +[root@destination]# virsh list --all + Id Name State +---------------------------------------------------- + +Attached the SOS report of the Source and Destination machines. + +Created attachment 767310 +source sos + +Created attachment 767311 +Destination sos + +Unfortunately, the libvirtd.log is missing. I've written some guide as well: + +http://wiki.libvirt.org/page/DebugLogs + +Please set the correct debug logs, reproduce and attach the new reports. + +Attached libvirtd logs of both Source and Destination + +Created attachment 767340 +source libvirtd log + +Created attachment 767342 +Destination libvird logs + +From the *source* libvirtd log: + +2013-07-01 11:30:29.582+0000: 3164: debug : virObjectRef:297 : OBJECT_REF: obj=0x7fe97000cb00 +2013-07-01 11:30:29.582+0000: 3164: error : qemuMonitorIORead:511 : Unable to read from monitor: Connection reset by peer +2013-07-01 11:30:29.582+0000: 3164: debug : qemuMonitorIO:644 : Error on monitor Unable to read from monitor: Connection reset by peer +2013-07-01 11:30:29.582+0000: 3164: debug : virObjectUnref:260 : OBJECT_UNREF: obj=0x7fe97000cb00 +2013-07-01 11:30:29.582+0000: 3165: debug : qemuMonitorSend:905 : Send command resulted in error Unable to read from monitor: Connection reset by peer +2013-07-01 11:30:29.582+0000: 3164: debug : qemuMonitorIO:678 : Triggering error callback +2013-07-01 11:30:29.582+0000: 3164: debug : qemuProcessHandleMonitorError:351 : Received error on 0x7fe9881337f0 'rhel64-64' + +This means, qemu died unexpectedly. The qemu error message should be in /var/log/libvirt/qemu/rhel64-64.log on the source. + +Since this is a qemu bug (probably fixed already) I'm closing this one. If you disagree please reopen. + diff --git a/results/classifier/108/other/1192780 b/results/classifier/108/other/1192780 new file mode 100644 index 00000000..19c85355 --- /dev/null +++ b/results/classifier/108/other/1192780 @@ -0,0 +1,181 @@ +other: 0.887 +permissions: 0.886 +debug: 0.861 +socket: 0.832 +semantic: 0.826 +network: 0.817 +device: 0.812 +performance: 0.806 +PID: 0.802 +graphic: 0.793 +KVM: 0.782 +files: 0.777 +vnc: 0.748 +boot: 0.747 + +qemu-kvm with snapshot option always fails with Permission denied Could not open disk image + +I'm trying to use the option: -snapshot write to temporary files instead of disk image files + +How to reproduce? See following log: +2013-06-20 02:13:18.532+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -S -M pc-1.0 -no-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-0000002b -uuid 2d600758-ae56-48b8-bd4d-999744a038e4 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0000002b.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -kernel /opt/stack/data/nova/instances/instance-0000002b/kernel -initrd /opt/stack/data/nova/instances/instance-0000002b/ramdisk -append root=/dev/vda console=ttyS0 -drive file=/opt/stack/data/nova/instances/instance-0000002b/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -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 -netdev tap,fd=19,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=fa:16:3e:03:ab:18,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/instance-0000002b/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:26868 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -snapshot +Domain id=1 is tainted: custom-argv +char device redirected to /dev/pts/18 +qemu-system-x86_64: -drive file=/opt/stack/data/nova/instances/instance-0000002b/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /opt/stack/data/nova/instances/instance-0000002b/disk: Permission denied +2013-06-20 02:13:18.683+0000: shutting down + +Version: QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard + +Related info: +The disk is a qcow2 image with a backing file. Both the backing file and the disk are cmodded with 777. + +This is a log from dmesg related to apparmor: +[ 236.531287] type=1400 audit(1371694399.156:17): apparmor="STATUS" operation="profile_remove" name="libvirt-2d600758-ae56-48b8-bd4d-999744a038e4" pid=4201 comm="apparmor_parser" + + +libvirt.xml that I'm using: +<domain type="qemu" xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + <uuid>2d600758-ae56-48b8-bd4d-999744a038e4</uuid> + <name>instance-0000002b</name> + <memory>524288</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <kernel>/opt/stack/data/nova/instances/instance-0000002b/kernel</kernel> + <initrd>/opt/stack/data/nova/instances/instance-0000002b/ramdisk</initrd> + <cmdline>root=/dev/vda console=ttyS0</cmdline> + </os> + <features> + <acpi/> + <apic/> + </features> + <clock offset="utc"/> + <devices> + <disk type="file" device="disk"> + <driver name="qemu" type="qcow2" cache="none"/> + <source file="/opt/stack/data/nova/instances/instance-0000002b/disk"/> + <target bus="virtio" dev="vda"/> + </disk> + <disk type="block" device="cdrom"> + <driver name="qemu" type="raw"/> + <target tray="open" dev="hdc"/> + <readonly/> + </disk> + <interface type="bridge"> + <mac address="fa:16:3e:03:ab:18"/> + <source bridge="br100"/> + <filterref filter="nova-instance-instance-0000002b-fa163e03ab18"> + <parameter name="IP" value="10.0.0.3"/> + <parameter name="DHCPSERVER" value="10.0.0.1"/> + <parameter name="PROJNET" value="10.0.0.0"/> + <parameter name="PROJMASK" value="255.255.255.0"/> + </filterref> + </interface> + <serial type="file"> + <source path="/opt/stack/data/nova/instances/instance-0000002b/console.log"/> + </serial> + <serial type="pty"/> + <input type="tablet" bus="usb"/> + <graphics type="vnc" autoport="no" port="32768" keymap="en-us" listen="127.0.0.1"/> + </devices> +<qemu:commandline> + <qemu:arg value='-snapshot'/> +</qemu:commandline> +</domain> + +On 06/19/2013 08:42 PM, Sam Stoelinga wrote: +> Public bug reported: +> +> I'm trying to use the option: -snapshot write to temporary files +> instead of disk image files +> + +> +> libvirt.xml that I'm using: +> <domain type="qemu" xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> + +> <qemu:commandline> +> <qemu:arg value='-snapshot'/> +> </qemu:commandline> +> </domain> + +This is unsupported usage of libvirt, and not a qemu bug. You'd need to +take this up with the libvirt list to get libvirt to properly support +temporary disk images without needing <qemu:commandline>, and so that +libvirt is properly setting SELinux permissions on the temporary file. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Hi, quick question, + I thought that using the <transient/> xml tag of <disk> element is the right way to do in libvirt ? +Why is <qemu:commandline> method being used ? + +Also with -snapshot, iiuc the temp. file is created by QEMU internally, so which temp. file and its selinux perms is being referenced above ? + + +On 07/25/2013 10:09 AM, Deepak C Shetty wrote: +> Hi, quick question, +> I thought that using the <transient/> xml tag of <disk> element is the right way to do in libvirt ? + +Yes, that is the designed way. Unfortunately, it has not been +implemented yet (no one has been clamoring for the feature enough to +write the patch themselves, or for someone else to take interest and +write a patch on their behalf). + +> Why is <qemu:commandline> method being used ? + +To try and work around the unimplemented nature of the libvirt design. + +> +> Also with -snapshot, iiuc the temp. file is created by QEMU internally, +> so which temp. file and its selinux perms is being referenced above ? +> + +Qemu creating a file itself when libvirt has set SELinux rules on the +qemu instance is very likely to fail, since qemu doesn't know what label +to give the temp file, but the temp file must be labeled to be used. +Hence, this really needs to be implemented properly in libvirt, and is +not a qemu bug. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 07/25/2013 10:32 AM, Eric Blake wrote: +> On 07/25/2013 10:09 AM, Deepak C Shetty wrote: +>> Hi, quick question, +>> I thought that using the <transient/> xml tag of <disk> element is the right way to do in libvirt ? +> +> Yes, that is the designed way. Unfortunately, it has not been +> implemented yet (no one has been clamoring for the feature enough to +> write the patch themselves, or for someone else to take interest and +> write a patch on their behalf). + +In particular, see this libvirt bug, which is stagnating due to +higher-priority bugs that I am working on first: + +https://bugzilla.redhat.com/show_bug.cgi?id=832194 + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Eric, + Thanks for the quick reply. I saw the <transient/> desc. in formatdomain.html and thought its supported. So does that mean its supported for other hypervisors but not QEMU/KVM ? If not supported at all, why does it show up in the doc... its misleading. + +I had a recent need to start exploiting this feature and landed up here. I am willing to work on supporting <transient/> with your guidance :) since I don't have much knowledge of SELinux. + +thanx, +deepak + +According to Eric's comments, this was a libvirt bug, not a QEMU bug, so closing this ticket now. If you still encounter this problem, please report it to the libvirt project instead. + |