Re: [Qemu-discuss] test1
On 23 September 2014 14:42, Paul Gydos p...@gydos.com wrote: your email goes out fine - it takes a half hour for the server to update Occasionally if the list server is having a bad day it can lag by hours, but mostly it's just a few minutes. If you're wondering if a mail you sent has gone out then it's better to check the list archives rather than sending a test email (the archives suffer from the same lag as other recipients, but on the other hand if the archive got a copy so did everybody else). thanks -- PMM
[Qemu-discuss] Make problem on migration-rdma.o
I just solved this problem at work. I was building qemu 2.0 on an ubuntu 12.04 machine. This error says there is a variable link_layer is missing in the struct ibv_port_attr That struct exists in the file /usr/include/infiniband/verbs.h. Your version of that file is older than qemu likes. In ubuntu that file is managed by the package libibverbs-dev http://packages.ubuntu.com/pt/trusty/libibverbs-dev If you build and install this package before building qemu your problem should be solved. -Nick
[Qemu-discuss] QEMU/KVM Bug: Sporadic freezing in Windows 2012R2
Hi All, I've run into a bug that I can't seem to solve and need some advice on what to do next. Environment is - Ubuntu 14.04 (Kernel 3.13-35) Qemu 2.1.1 Dual Ivy Bridge-EP E5-2697 v2 256GB The problem I'm having is that a reasonably large guest (48gb, 12cpu) running Server 2012R2 standard will hang for 2-5 seconds under load (~60% CPU and even under 10%) every 30 to 90 minutes. Any monitoring on the guest shows that CPU usage jumps to 100% during the freeze and the Windows perfmon tool shows a gap in CPU usage reporting indicating that it's not doing anything at all during the freeze and skipping interupts. During the freeze the guest replys to pings very slowly at 1000ms. Current command line is - qemu-system-x86_64 -enable-kvm -name ServerWithProblem -S -machine pc-q35-2.1,accel=kvm,usb=off -cpu qemu64,-svm -m 49152 -realtime mlock=off -smp 12,sockets=12,cores=1,threads=1 -uuid 6b5cecbf-385e-43a1-b894-99b72efcae8b -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ServerWithProblem.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -no-hpet -no-shutdown -boot order=c,menu=on,strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -drive file=rbd:ssd/ServerWithProblem:auth_supported=none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback,aio=threads -device virtio-blk-pci,ioeventfd=off,event_idx=off,scsi=off,bus=pci.2,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/libvirt/images/vio.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:21:54:7f,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:4 -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x3 What I've tried so far is - Different QEMU version (2.0-ubuntu, 2.0 source, 2.1, 2.1.1) Different kernels (3.13-ubuntu, 3.15.8, 3.16.2) Different machine type (Q35 vs i440) Enable and disable Hyper-v enlightenments Change guest CPU type (QEMU64 vs Sandy Bridge vs Host) Disable APICV usage in the kvm_intel module Enable/Disable KSM and numa balancing All of that and so far it's still occurring no matter what. Disabling APICV in the kvm module appears to have made the freezes a little shorter (~2 seconds) but I can't say that with absolute certainty. I've tried to replicate the problem on another host with Nehalem CPU's but haven't seen the same issue. I wrote a small script to ping the guest and trigger a perf record for 5 seconds during the freeze and got the below details - Kernel 3.13-25, Qemu 2.1.1, guest has all HV enlightenments enabled, kvm_intel with apicv disabled # Overhead Command Shared Object Symbol # ... .. .. # 14.93% qemu-system-x86 [kernel.kallsyms] [k] native_write_msr_safe 13.44% qemu-system-x86 [kernel.kallsyms] [k] vmx_vcpu_run 13.13% qemu-system-x86 [kernel.kallsyms] [k] fget_light 11.73% qemu-system-x86 [kernel.kallsyms] [k] x86_decode_insn 9.80% qemu-system-x86 [kernel.kallsyms] [k] vmx_vcpu_load 9.71% qemu-system-x86 [kernel.kallsyms] [k] mmu_set_spte 6.19% qemu-system-x86 [kernel.kallsyms] [k] update_cfs_shares 5.19% qemu-system-x86 [kernel.kallsyms] [k] x86_emulate_instruction 4.68% qemu-system-x86 [kernel.kallsyms] [k] _raw_spin_lock_irqsave 3.26% qemu-system-x86 [kernel.kallsyms] [k] enqueue_entity 3.00% qemu-system-x86 [kernel.kallsyms] [k] pte_list_add 2.63% qemu-system-x86 qemu-system-x86_64 [.] 0x000de670 0.71% qemu-system-x86 [kernel.kallsyms] [k] rcu_irq_exit 0.66% qemu-system-x86 [kernel.kallsyms] [k] generic_smp_call_function_single_interrupt 0.64% qemu-system-x86 [kernel.kallsyms] [k] remote_function 0.28% qemu-system-x86 [kernel.kallsyms] [k] kvm_arch_vcpu_load Can anyone suggest where I go from here to track down the issue? Thanks
Re: [Qemu-discuss] test1
Oh, I found my original test1 email is in the SPAM mail box. For some reason, after I send HTML body'ed email to the list server, and it is reflected to my organization's email server, it is regarded as SPAM (mails sent from qemu-discuss-bounces+ckim=etri.re...@nongnu.orgmailto:qemu-discuss-bounces+ckim=etri.re...@nongnu.org) So I removed the SPAM filter rule. Thanks! Chan 보낸 사람 : Peter Maydell peter.mayd...@linaro.org 보낸 날짜 : 2014-09-23 22:55:14 ( +09:00 ) 받는 사람 : Paul Gydos p...@gydos.com 참조 : 김찬 c...@etri.re.kr, qemu-discuss qemu-discuss@nongnu.org 제목 : Re: [Qemu-discuss] test1 On 23 September 2014 14:42, Paul Gydos wrote: your email goes out fine - it takes a half hour for the server to update Occasionally if the list server is having a bad day it can lag by hours, but mostly it's just a few minutes. If you're wondering if a mail you sent has gone out then it's better to check the list archives rather than sending a test email (the archives suffer from the same lag as other recipients, but on the other hand if the archive got a copy so did everybody else). thanks -- PMM
Re: [Qemu-discuss] Help with -kernel option (unable to mount root fs)
On 24-09-2014 03:18, Martin Ichilevici de Oliveira wrote: Hello, I'm trying to use the -kernel option of QEMU, in order to later debug Linux with GDB, but I've been unable to boot the system. My setup: a working CentOS 7 with a manually compilled kernel (3.17-rc5). If I simply boot the image with qemu-system-x86_64, it works fine. So I copied the bzImage out of the VM and ran: $ qemu-system-x86_64 -m 4G -hda image.img -kernel bzImage -append root=/dev/sda console=ttyS0 -nographic root=/dev/sda is clearly wrong, that is the whole unpartitioned disk, not the root partition inside it. You probably want /dev/sda1. But morebelow... The system failed to boot (log at the end of this email), but basically it's complaining about being unable to mount the root filesystem. I thought I'd used the wrong /dev/sdX on the append option, so I checked with # fdisk -l Did you run this command on the guest? Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x000a2200 Device Boot Start End Blocks Id System /dev/sda1 *2048 1026047 512000 83 Linux /dev/sda2 10260486291455930944256 8e Linux LVM I take that to mean that /dev/sda1 is a small 512MB partition containing grub, kernels, initrd images etc. Probably mounted as /boot by the guest once it is running. /dev/sda2 is subpartitioned using LVM and I am not sure the built in root mounting code in the kernel can handle that without help from user mode tools in an initrd. You need to look in the grub config for the file name of that initrd image, then pass that to qemu along with the kernel image and the required kernel commandline. The kernel will run the initrd before it tries to mount root, and the initrd (presumably generated automatically by CentOS) will then load the needed LVM tools to find /dev/mapper/centos-root and mount it as root. Disk /dev/mapper/centos-swap: 3221 MB, 3221225472 bytes, 6291456 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/centos-root: 10.5 GB, 1048576 bytes, 2048 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/centos-home: 18.0 GB, 17976786944 bytes, 35110912 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Not many options here... I tried with /dev/sda1, /dev/sda2 and /dev/mapper/centos-root, but all got the same error. Finally, I checked the grub entry for that kernel and it contains: set root='hd0,msdos1' I guess this line is just there to help grub find the kernel and initrd, then otherparameters will make the initrd tell the kernel where the real root is. Note that grub, for unfathomable reasons, has its own weird naming of partitions. hd0,msdos1probably means /dev/sda1 (the small boot partition), or it could mean /dev/sda2 (the LVMcontainer, which obviously won't be used directly as root). But I'm not really sure how to use this information. Any help is appreciated. Thank you, Martin Kernel panic log: (...) [2.278415] List of all partitions: [2.279764] No filesystem could mount root, tried: [2.281594] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [2.282071] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6+ #1 [2.282071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014 [2.282071] 724949f3 88003daabd60 81686bcd [2.282071] 818ba3c0 88003daabde8 81683afb 0010 [2.282071] 88003daabdf8 88003daabd90 724949f3 724949f3 [2.282071] Call Trace: [2.282071] [81686bcd] dump_stack+0x45/0x56 [2.282071] [81683afb] panic+0xd5/0x209 [2.282071] [81b3d5ec] mount_block_root+0x2a4/0x2b3 [2.282071] [81b3d64e] mount_root+0x53/0x56 [2.282071] [81b3d78d] prepare_namespace+0x13c/0x174 [2.282071] [81b3d25a] kernel_init_freeable+0x23d/0x261 [2.282071] [8167a3d0] ? rest_init+0x80/0x80 [2.282071] [8167a3de] kernel_init+0xe/0xf0 [2.282071] [8168ebbc] ret_from_fork+0x7c/0xb0 [2.282071] [8167a3d0] ? rest_init+0x80/0x80 [2.282071] Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) [2.282071] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [2.282071] general protection
Re: [Qemu-discuss] Help with -kernel option (unable to mount root fs)
Jakob, Thanks for the quick reply, your comments helped me solve it. Analyzing the grub config file in more details cleared it all, as it contained the initrd image to use and the correct disk. After copying the initrd to the host, I was able to boot the system with the command below: $ qemu-system-x86_64 -m 4G -hda image.img -kernel ./bzImage -initrd ./initramfs-3.17.0-rc5.img -append root=/dev/mapper/centos-root console=ttyS0 -nographic Enjoy I sure will :) Cheers, Martin pgpNblJdNhwb1.pgp Description: PGP signature
