[Bug 1711602] Re: --copy-storage-all failing with qemu 2.10
Please see Fam's patch series "[PATCH for-2.10 0/4] block: Fix non- shared storage migration" that fixes this issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1711602 Title: --copy-storage-all failing with qemu 2.10 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1711602/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1687653] Re: QEMU-KVM / detect_zeroes causes KVM to start unlimited number of threads on Guest-Sided High-IO with big Blocksize
After further investigation on IRC the following points were raised: 1. Non-vcpu threads in QEMU weren't being isolated. Libvirt can do this using the domain XML element. The guest can create a high load if some QEMU threads are unconstrained. 2. The wait% CPU stat was causing confusion. It's the idle time during which synchronous I/O is pending. High wait% does not mean that the system is under high CPU load. detect-zeroes=on can take a synchronous I/O path even when aio=native is used, and this results in wait% instead of idle%. I'm closing the bug. ** Changed in: qemu Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1687653 Title: QEMU-KVM / detect_zeroes causes KVM to start unlimited number of threads on Guest-Sided High-IO with big Blocksize To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1687653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1687653] Re: QEMU-KVM / detect_zeroes causes KVM to start unlimited number of threads on Guest-Sided High-IO with big Blocksize
I'm unable to reproduce this issue. The host stays responsive and the dd command completes in a reasonable amount of time. QEMU does not exceed the 64-thread pool size. Please post steps to reproduce the issue using a minimal command-line without libvirt. Here is information on my attempt to reproduce the problem: Guest: Kernel 4.10.8-200.fc25.x86_64 Host: 4.10.11-200.fc25.x86_64 QEMU: qemu.git/master (e619b14746e5d8c0e53061661fd0e1da01fd4d60) The LV is 1 GB on top of LUKS on a Samsung MZNLN256HCHP SATA SSD drive. mpstat -P ALL 5 output: 11:02:02 AM CPU%usr %nice%sys %iowait%irq %soft %steal %guest %gnice %idle 11:02:07 AM all3.360.006.22 34.540.250.500.00 3.110.00 52.03 11:02:07 AM02.820.005.63 32.390.801.210.00 3.220.00 53.92 11:02:07 AM13.020.006.04 28.770.200.200.00 3.020.00 58.75 11:02:07 AM23.560.007.71 44.270.200.400.00 2.370.00 41.50 11:02:07 AM33.810.005.61 32.460.000.400.00 4.010.00 53.71 vmstat 5 output: procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 0 0 0 1617404 6484 354146800 2145 84794 1976 8814 8 8 64 20 0 0 0 0 1619492 6484 353859200 613 69340 1518 7430 6 7 70 17 0 0 0 0 1618920 6484 353868000 280 75199 1421 6811 6 7 52 35 0 pidstat -v -p $PID_OF_QEMU 5 output: 11:01:08 AM UID PID threads fd-nr Command 11:02:03 AM 0 13043 67 37 qemu-system-x86 11:02:08 AM 0 13043 67 37 qemu-system-x86 11:02:13 AM 0 13043 67 37 qemu-system-x86 $ sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -cpu host \ -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 \ -drive file=test.img,if=none,id=drive-scsi0,format=raw,cache=none,aio=native,detect-zeroes=on \ -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100 \ -drive file=/dev/path/to/testlv,if=none,id=drive-scsi1,format=raw,cache=none,aio=native,detect-zeroes=on \ -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi1,id=scsi1,bootindex=101 \ -nographic guest# dd if=/dev/zero of=/dev/sdb bs=1G count=1 oflag=direct 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.0681 s, 71.3 MB/s -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1687653 Title: QEMU-KVM / detect_zeroes causes KVM to start unlimited number of threads on Guest-Sided High-IO with big Blocksize To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1687653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1192499] Re: virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer"
> "migrate -b tcp ::1234" There should be no space between tcp and the rest of the connection details: migrate -b tcp::1234 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1192499] Re: 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 ::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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1192499 Title: virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1192499/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Qemu-devel] [Bug 1025244] Re: qcow2 image increasing disk size above the virtual limit
On Tue, Dec 18, 2012 at 10:18:20AM -, Andy Menzel wrote: > Any solution right now? I have a similar problem like Todor Andreev; > Our daily backup of some virtual machines (qcow2) looks like that: > > 1. shutdown the VM > 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..." > 3. boot the VM > 4. backup the snapshot to another virtual disk via: "qemu-img convert -f > qcow2 -O qcow2 -s nameofsnapshot..." > 5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot... It's not safe to modify the qcow2 file while the guest is running. This means Step 5 is not really safe and could result in an inconsistent image. This may also be causing the problem: the QEMU process has a variable with the next free cluster index. Since Step 5 runs as a separate process it does not update the QEMU process' next free cluster index variable. QEMU doesn't know that there are now free clusters within the image file because you updated the file behind QEMU's back - the result is that it grows the file. Please try deleting the last backup snapshot between Step 1 and Step 2. This way you'll free the space while QEMU isn't accessing the image file. When you boot up the image file again QEMU should reuse the freed clusters. Stefan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1025244 Title: qcow2 image increasing disk size above the virtual limit To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1025244/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1079713] Re: [Qemu-devel] [PATCH 1.3] qapi: handle visitor->type_size() in QapiDeallocVisitor
On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber wrote: > Am 26.11.2012 13:10, schrieb Stefan Hajnoczi: >> visit_type_size() requires either visitor->type_size() or >> visitor_uint64() to be implemented, otherwise a NULL function pointer is >> invoked. >> >> It is possible to trigger this crash as follows: >> >> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \ >>-device virtio-blk-pci,netdev=netdev0 >> >> The 'sndbuf' option has type "size". >> >> Signed-off-by: Stefan Hajnoczi >> --- >> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3. > > Reviewed-by: Andreas Färber > > Did you check whether any other types were unhandled? The visitors do not handle all types. Only the opts visitor and now the dealloc visitor handle ->type_size(). This will not cause a problem yet because only the netdev options include fields with the 'size' type. That code path is now covered. In the longer term we should clean up the int, number, uint64, size type proliferation and handle them consistently. > Should a comment be added somewhere along the lines of "If you add a > hook here you also need to implement one there" to avoid such > inconsistency for the future? There is no single point like register_visitor() where we could check that callbacks are set up. That would have been a nice way to prevent incomplete visitors. The issue is that qapi/qapi-visit-core.h says type_uint64 and type_size may be NULL, but it documents that visit_type_size() falls back to type_uint64() if type_size() is NULL. The case we hit was that type_uint64() is also NULL. Should it fall back to type_int() (int64_t)? Stefan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1079713 Title: failed to set sndbuf on VMs network interface To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1079713/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1035921] Re: odd IO/load behaviour running debian installer guest
Please use cache=none for disks. The default cache setting is "writethrough" which means the image file is opened with O_DSYNC. Every single write is flushed to disk. Modern guests run much faster using cache=none and data is safe as long as the guest issues cache flushes when appropriate (which modern guests/apps do). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1035921 Title: odd IO/load behaviour running debian installer guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1035921/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 658610] Re: Check whether images have write permissions
Can you please add steps to reproduce this bug? It's not clear to me when this happens. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/658610 Title: Check whether images have write permissions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
