[Qemu-discuss] Qemu failed if specify reconnect=1 for vhost-user-blk socket
Hi, all. I'm using Qemu with SPDK. When specify option "reconnect=1" for vhost-user-blk socket, the Qemu will exited with error: 2018-08-17T03:39:21.768809Z qemu-system-x86_64: -device vhost-user-blk-pci,id=blk0,chardev=char0,num-queues=4: Failed to set msg fds. 2018-08-17T03:39:21.768893Z qemu-system-x86_64: -device vhost-user-blk-pci,id=blk0,chardev=char0,num-queues=4: vhost-user-blk: vhost initialization failed: Operation not permitted The whole command line is: /root/wzh/qemu-2.12.0/build/x86_64-softmmu/qemu-system-x86_64 \ -name guest=wzh,debug-threads=on \ -machine pc-i440fx-2.12,accel=kvm,usb=off,dump-guest-core=off \ -cpu host \ -m 2048 \ -object memory-backend-file,id=mem0,size=2G,mem-path=/dev/hugepages,share=on \ -numa node,memdev=mem0 \ -realtime mlock=off \ -smp 32,sockets=16,cores=2,threads=1 \ -uuid a84e96e6-2c53-408d-986b-c709bc6a0e51 \ -no-user-config \ -nodefaults \ -rtc base=utc,driftfix=slew \ -global kvm-pit.lost_tick_policy=delay \ -no-shutdown \ -boot strict=on \ -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ -device ahci,id=sata0,bus=pci.0,addr=0x4 \ -drive file=/root/wzh/wzh.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=0 \ -device usb-tablet,id=input0,bus=usb.0,port=1 \ -vnc :0 \ -k en-us \ -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ -msg timestamp=on \ -chardev socket,id=char0,path=/var/tmp/vhost.0,reconnect=1 \ -device vhost-user-blk-pci,id=blk0,chardev=char0,num-queues=4 The Qemu works fine if I just remove option "reconnect=1". Does Qemu doesn't support this option for SPDK's vhost-user-blk, or did I made a stupid mistake? Thanks for any advice. OS: CentOS 7.4 Qemu: 2.12.0 SPDK: 9ee494213 in master
Re: [Qemu-discuss] qcow2 performanceimprove
On 17/08/2018 04:28, yang.bi...@zte.com.cn wrote: If there is no backing file or snapshot you still need to fill the>>>cluster with zeroes, and that's going to be slower with larger>>>clusters. If not fill zeroes and only write guest data ,what`s wrong could>> happen ?>The following could happen:> 1) Guest reads at offset [0, 4k] -> there's only zeroes> 2) Guest writes at offset [8k, 16k]> 3) Guest reads at offset [0, 4k] -> there's something else now>Berto Why could guest read the area at offset [0, 4k] has not be writen yet ? Yang.bin Because on any real computer (which qemu emulates), you can read any sector of a disk, even if it only contains whatever the disk factory put there during manufacture, usually something like 0x00, 0xA5, 0xFF etc. qcow2 unallocated virtual disk clusters contain 0x00 when read and there are commands that convert all-0x00 clusters back to being unallocated. So if a a guest machine issues a write to only part of a qcow2 unallocated cluster, the qcow2 needs to emulate that the rest of that qcow2 cluster still contains the 0x00. qcow2 might do that either by actually writing 0x00 to wherever it now allocated a full qcow2 cluster of storage in order to save the changed part, or create a complex data structure to remember which part of which cluster is virtually zero but not actually stored anywhere. Either way has speed overhead, but the first is usually the fastest. Now if the qcow2 file is created with the same qcow2 cluster size as the actual cluster size in the guest filesystem, and the start of the guest file system is aligned so all filesystem clusters start at disk offsets that are multiples of the filesystem cluster size (already required for physical disks with 4096-byte sectors), then this partial write scenario will happen vary rarely. That cluster size to cluster size alignment is generally a best practice for performance of thin provisioned virtual disks of all kinds, not just for qcow2 or other qemu formats. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: [Qemu-discuss] qcow2 performanceimprove
>>>If there is no backing file or snapshot you still need to fill the>>>cluster >>>with zeroes, and that's going to be slower with larger>>>clusters. >>>If not fill zeroes and only write guest data ,what`s wrong could>> >>>happen ?>The following could happen:> 1) Guest reads at offset [0, 4k] -> >>>there's only zeroes> 2) Guest writes at offset [8k, 16k]> 3) Guest reads at >>>offset [0, 4k] -> there's something else now>Berto Why could guest read the area at offset [0, 4k] has not be writen yet ? Yang.bin
[Qemu-discuss] Handling signal of Qemu thread
I am registering a signal handler per Qemu thread (per VCPU) and expecting to handle it in that thread context. But I never receive the signal on the Qemu thread that is causing the event, rather the signal is sent to parent thread context. Can you please explain the reason behind this? I also see that Qemu has a function called "kvm_eat_signals". Does it have to do anything with my issue? Regards, Probir
Re: [Qemu-discuss] [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
Daniel P. Berrangé: > On Fri, Aug 10, 2018 at 08:33:00PM +, procmem wrote: >> Hello. I'm a distro maintainer and was wondering about the efficacy of >> entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the >> authors of haveged [0] pointed out if the hardware cycles counter is >> emulated and deterministic, and thus predictible. He therefore does not >> recommend using HAVEGE on those systems. Is this the case with KVM's >> counters? >> >> PS. I will be setting VM CPU settings to host-passthrough. > > Hardware from circa 2011 onwards has RDRAND support, and with host-passthrough > this will be available to the guest. The rngd daemon, running in the guest, > can use this as a source to feed the kernel entropy. > > In addition QEMU has support for virtio-rng which can pull entropy from > /dev/urandom on the host, and feed it into the guest, where again rngd can > give it to the kernel. > > So why do you need to consider haveged / jitterentropyd at all with QEMU ? > It should suffice to just enable virtio-rng in the host and run rngd in > all guests. If the host has RDRAND, that's an extra bonus. > > haveged / jitterentropyd should only be needed on other non-QEMU hypervisors > which don't support something equiv to virtio-rng, and are on hardware that > is too old for RDRAND. > > Regards, > Daniel > Makes sense. Thanks for your answer.
Re: [Qemu-discuss] [libvirt-users] Efficacy of jitterentropy RNG on qemu-kvm Guests
Martin Kletzander: > On Fri, Aug 10, 2018 at 08:33:00PM +, procmem wrote: >> Hello. I'm a distro maintainer and was wondering about the efficacy of >> entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the >> authors of haveged [0] pointed out if the hardware cycles counter is >> emulated and deterministic, and thus predictible. He therefore does not >> recommend using HAVEGE on those systems. Is this the case with KVM's >> counters? >> > > I don't know the answer. But try asking on qemu-discuss@nongnu.org or > maybe > KVM-related ML. > > Have a nice day, > Martin > Thanks. Yes I had already sent there. Waiting patiently for an answer :)
Re: [Qemu-discuss] Request for information inclusion on the wiki links page section of QEMU project!
Thanks, Thomas! I understand your point of view and your opinion! I am sorry! By the way, when I can to develop JavaQemu again, and to focus on the latest version of Qemu software, then I will request the information inclusion on the wiki page of Qemu software again. Best Regards,Daniel Bruno. Em quinta-feira, 16 de agosto de 2018 03:48:53 BRT, Thomas Huth escreveu: On 08/15/2018 04:22 PM, daniel silva ferreira bruno wrote: > Hi, staff of QEMU project! > I am Daniel Silva Ferreira Bruno, creator of the JavaQEMU Open Source > Software, available at:https://sourceforge.net/projects/javaqemu/. > JavaQemu is a Graphical User Interface Front End for QEMU, written in Java > Programming Language! > I would like the JavaQemu project information to be included in the "GUI > Front Ends" section of the wiki page of QEMU project, available > at:https://wiki.qemu.org/Links, please. According to that page at Sourceforge, "This project is no longer active because I stopped playing with Java since a long time" and the last release is also more than 3 years old. Honestly, I don't think we should put links to dead projects into the wiki, that's just a bad experience for the users if they try out a front-end software that likely does not work with the latest version of QEMU anymore. Having said that, I think we can remove most of the other GUI entries in the Wiki nowadays, since they seem to be pretty much out-of-date. Thomas
Re: [Qemu-discuss] qcow2 performance improve
On Thu 16 Aug 2018 10:20:12 AM CEST, yang.bi...@zte.com.cn wrote: >>If there is no backing file or snapshot you still need to fill the >>cluster with zeroes, and that's going to be slower with larger >>clusters. > > If not fill zeroes and only write guest data ,what`s wrong could > happen ? The following could happen: 1) Guest reads at offset [0, 4k] -> there's only zeroes 2) Guest writes at offset [8k, 16k] 3) Guest reads at offset [0, 4k] -> there's something else now Berto
Re: [Qemu-discuss] qcow2 performance improve
> > > > When use cluster_size=1M qcow2 newly created to test "32k rand > > > > write" in the VM,We get low performance within VM。But there > > > > are huge “write” requests in HOST which falls into qemu > > > > stack of"perform_cow". > > > The reason why this happens is because clusters are the smallest > > > units of allocation in qcow2. So if you write a new cluster you > > > have to fill it completely with data. If there was any existing > > > data (backing file, snapshot), you need to copy it from there. > > > If cluster_size=1M then every time you send a write request that > > > needs to allocate a new cluster then you need to write 1MB. It > > > doesn't matter if the write request is 32KB, 4KB or 512 bytes. > > But Our image has not backing file or snapshot. >If there is no backing file or snapshot you still need to fill the >cluster with zeroes, and that's going to be slower with larger >clusters. If not fill zeroes and only write guest data ,what`s wrong could happen ? >More information here: > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01229.html >There's work to improve that scenario (allocating a new cluster with no >backing file or snapshots), here are some patches: > http://lists.nongnu.org/archive/html/qemu-block/2018-05/msg00180.html >More information about those patches here: > http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00059.html >And that's for the "no backing file" case. The more general solution >would be the subcluster allocation feature that I mentioned in my >previous e-mail: > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01033.html >I gave a presentation last year at the KVM Forum about performance >with the qcow2 format: > https://www.youtube.com/watch?v=kmUxIOTiGNo >Another earlier talk on the same topic by Max Reitz and Kevin Wolf: > https://www.youtube.com/watch?v=svMpxzl9yI4 >I hope that helps, >Berto
[Qemu-discuss] question about qemu debug xv6 operation system kernal.
Hi, here I find some QEMU-build in commands: https://pdos.csail.mit.edu/6.828/2017/labguide.html I had install default qemu at ubuntu16.04 ,(qemu 2.5.0 monitor),I enter debug mode like this: qemu-system-i386 -hda obj/kern/kernel.img -monitor stdio -gdb tcp::26000 -D qemu.log after enter QEMU-monitor,I run " info pg ",it show "unknown command...",why? is that command has removed from qemu? is there right command to show the page-table? thank you. krishna
Re: [Qemu-discuss] Request for information inclusion on the wiki links page section of QEMU project!
On 08/15/2018 04:22 PM, daniel silva ferreira bruno wrote: > Hi, staff of QEMU project! > I am Daniel Silva Ferreira Bruno, creator of the JavaQEMU Open Source > Software, available at:https://sourceforge.net/projects/javaqemu/. > JavaQemu is a Graphical User Interface Front End for QEMU, written in Java > Programming Language! > I would like the JavaQemu project information to be included in the "GUI > Front Ends" section of the wiki page of QEMU project, available > at:https://wiki.qemu.org/Links, please. According to that page at Sourceforge, "This project is no longer active because I stopped playing with Java since a long time" and the last release is also more than 3 years old. Honestly, I don't think we should put links to dead projects into the wiki, that's just a bad experience for the users if they try out a front-end software that likely does not work with the latest version of QEMU anymore. Having said that, I think we can remove most of the other GUI entries in the Wiki nowadays, since they seem to be pretty much out-of-date. Thomas
