ntfs -> qemu -> raw-image -> btrfs -> iscsi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello group,

does anyone have had any luck with hosting qemu kvm images resided on BTRFS filesystem while serving
the volume via iSCSI?

I encouraged some unidentified problem and I am able to replicate it. Basically the NTFS filesystem
inside RAW image gets corrupted every time when Windows guest boots. What is weired is that changing
filesystem for ext4 or xfs solves the issue.

The problem replication looks as follows:
1) run chkdsk on the guest to make sure the filesystem structure is in good shape,
2) shut down the VM via libvirtd,
3) rsync changes between source and backup image,
4) generate SHA1 for backup and original and compare it,
5) try to run guest on the backup image, I was able to boot windows once for ten times, every time
after reboot NTFS' chkdsk finds problems with filesystem and the VM is unable to boot again.

What am I missing?

VM disk config:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source file='/var/lib/libvirt/images/windows2012r2.img'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

Initiator side:

root@initiator:~# btrfs version
btrfs-progs v4.13.3
root@initiator:~# uname -a
Linux initiator 4.15.0-0.bpo.2-amd64 #1 SMP Debian 4.15.11-1~bpo9+1 (2018-04-07) x86_64 GNU/Linux
root@initiator:~# btrfs version
btrfs-progs v4.13.3
root@initiator:~# cat /etc/debian_version
9.4
root@initiator:~# iscsid -v
iscsid version 2.0-874

BTRFS mount options:
_netdev,noatime,nodiratime,compress=lzo

Target side:

root@target:~# dpkg -l | grep iscsi
ii  iscsitarget                     1.4.20.2-10.1                  armel        iSCSI Enterprise
Target userland tools
root@target:~# uname -a
Linux target 2.6.31.8 Mon Nov 23 04:30:20 CET 2015 v0.0.9 Mon Nov 23 04:30:20 CET 2015 armv5tel
GNU/Linux

PS. There's nothing interesting in dmsg, besides (target side):
iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
iscsi_trgt: cmnd_skip_pdu(459) 5e000000 1c 85 0
Which seems to be harmless and is probably generated by smartd.




--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux