Re: [Qemu-discuss] Content mismatch at offset 6577717248!

[Andrew Cagney]

Sigh, this, tucked away in dmesg, looks suspicious:

[108985.457106] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s!
[qemu-img:29934]
[108985.457110] Modules linked in: vhost_net vhost macvtap macvlan
nls_utf8 isofs loop nf_conntrack_netbios_ns nf_conntrack_broadcast ccm
xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter
ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute
bridge ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
iptable_security iptable_raw bnep uvcvideo videobuf2_vmalloc
videobuf2_core btusb videobuf2_memops v4l2_common btrtl videodev btbcm
btintel iTCO_wdt snd_hda_codec_hdmi media snd_hda_codec_realtek
snd_hda_codec_generic iTCO_vendor_support intel_rapl bluetooth
snd_hda_intel iosf_mbi snd_hda_codec
[108985.457143]  x86_pkg_temp_thermal coretemp arc4 snd_hda_core
kvm_intel iwldvm snd_hwdep snd_seq mac80211 snd_seq_device kvm snd_pcm
samsung_laptop snd_timer snd crct10dif_pclmul crc32_pclmul
crc32c_intel tpm_tis soundcore iwlwifi cfg80211 rfkill shpchp joydev
mei_me i2c_i801 mei lpc_ich tpm dell_smo8800 wmi intel_rst binfmt_misc
i915 i2c_algo_bit drm_kms_helper drm serio_raw 8021q garp stp llc mrp
r8169 mii video
[108985.457170] CPU: 2 PID: 29934 Comm: qemu-img Tainted: G        W
    4.2.8-200.fc22.x86_64 #1
[108985.457172] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[108985.457174] task: ffff8801fb261d80 ti: ffff88014dba0000 task.ti:
ffff88014dba0000
[108985.457175] RIP: 0010:[<ffffffff811a525b>]  [<ffffffff811a525b>]
find_get_pages+0xcb/0x1b0
[108985.457182] RSP: 0018:ffff88014dba3ca8  EFLAGS: 00000297
[108985.457183] RAX: ffff88012103c8f8 RBX: 000000000000000c RCX:
ffff88014dba3d90
[108985.457185] RDX: 000000000016adc0 RSI: ffff88014dba3cb8 RDI:
0000000000000000
[108985.457186] RBP: ffff88014dba3d08 R08: 0000000000000000 R09:
000000000016adbf
[108985.457187] R10: 0000000000000000 R11: 0000000000000220 R12:
000000000000000c
[108985.457188] R13: 000000000014f000 R14: 0000000000000000 R15:
0000000000000220
[108985.457190] FS:  00007ff0fef259c0(0000) GS:ffff88021fa80000(0000)
knlGS:0000000000000000
[108985.457191] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[108985.457192] CR2: 00007f80f1e41000 CR3: 0000000215c86000 CR4:
00000000000406e0
[108985.457194] Stack:
[108985.457195]  ffff88014dba3e38 ffff88014dba3d90 000000000016ad8e
000000000016adc0
[108985.457197]  0000000001000000 00000000e64b1606 0000000000000000
ffff88014dba3d80
[108985.457199]  00000000000dce5f 00000001231a2000 0000000000000003
00000000001231a2
[108985.457201] Call Trace:
[108985.457207]  [<ffffffff811b1bb2>] pagevec_lookup+0x22/0x30
[108985.457211]  [<ffffffff812a297f>]
ext4_find_unwritten_pgoff.isra.12+0xaf/0x300
[108985.457215]  [<ffffffff812a85db>] ? ext4_map_blocks+0x5b/0x4a0
[108985.457218]  [<ffffffff813a2adb>] ? rb_next+0x2b/0x40
[108985.457220]  [<ffffffff812a2e94>] ext4_llseek+0x2c4/0x3e0
[108985.457225]  [<ffffffff8121df42>] SyS_lseek+0x92/0xb0
[108985.457228]  [<ffffffff81023925>] ? syscall_trace_leave+0xb5/0x110
[108985.457233]  [<ffffffff8177a2ae>] entry_SYSCALL_64_fastpath+0x12/0x71
[108985.457234] Code: 48 3b 3b 0f 85 e3 00 00 00 44 89 f8 41 83 c7 01
45 39 fd 48 89 3c c1 74 4c 8b 45 b8 83 e8 01 2b 45 b0 48 8d 04 c3 48
39 c3 74 18 <48> 83 c3 08 48 83 45 b0 01 48 83 3b 00 74 ec 48 85 db 0f
85 6e

On 27 January 2016 at 13:08, Andrew Cagney <address@hidden> wrote:
> I'm creating a bunch of VMs that share a copy-on-write disk image
> using the sequence:
>
> - create a raw disk image using virt-install:
>
> fallocate -l 8G '/home/build/pool/swanfedorabase.img'
> sudo virt-install \
>     --connect=qemu:///system \
>     --network=network:default,model=virtio \
>     --initrd-inject=testing/libvirt/fedorabase.ks \
>     --extra-args="swanname=swanfedorabase ks=file:/fedorabase.ks
> console=tty0 console=ttyS0,115200" \
>     --name=swanfedorabase \
>     --disk path='/home/build/pool/swanfedorabase.img' \
>     --ram 1024 \
>     --vcpus=1 \
>     --check-cpu \
>     --accelerate \
>     --location=Fedora-Server-DVD-x86_64-21.iso \
>     --nographics \
>     --noreboot \
>     --hvm
>
> - converting the raw image to .qcow2:
>
> rm -f /home/build/pool/swanfedorabase.qcow2
> sudo qemu-img convert -O qcow2 '/home/build/pool/swanfedorabase.img'
> '/home/build/pool/swanfedorabase.qcow2'
>
> - creating copies of the qcow master:
>
> sudo qemu-img create -F qcow2 -f qcow2 -b
> '/home/build/pool/swanfedorabase.qcow2' '/home/build/pool/east.qcow2'
>
> - and finally attatch that to a VM
>
> I'm finding that the final image in the clones can be corrupt (empty
> files, checksum failures, ...); going back and booting the master vm
> and everything checks out :-/
>
> Any suggestions on how to track this problem down (or perhaps a better
> way to do this?).
>
> Andrew
>
> Fedora release 22 (Twenty Two)
> $ qemu-img --version
> qemu-img version 2.3.1 (qemu-2.3.1-10.fc22), Copyright (c) 2004-2008
> Fabrice Bellard