Description of problem: If you have, say, a Windows guest which has a data disk (D:) then virt-v2v won't consider it as a candidate for fstrim, and thus copying the data disk will be much slower than it ought to be. Virt-v2v should consider all mountable filesystems as candidates for fstrim. Version-Release number of selected component (if applicable): libguestfs 1.27.60 How reproducible: 100% Steps to Reproduce: 1. Create a Windows guest with a data disk. 2. Use virt-v2v to convert it. 3. Notice (in debug output) that data disk is not 'fstrim'-ed. Additional info: Reported by James Mighion
Fixed in: https://github.com/libguestfs/libguestfs/commit/69fe3945b7641811c99c3c03e05e73d2347e8a42 https://github.com/libguestfs/libguestfs/commit/e66138fbe71c24df3a282e1b23d8ed5c80f7b8c7 virt-v2v >= 1.27.61.
Try to verify with new build: virt-v2v-1.28.1-1.2.el7.x86_64 libguestfs-1.28.1-1.2.el7.x86_64 libguestfs-winsupport-7.1-4.el7.x86_64 steps: 1. Prepare a win7 guest on xen server with two disk(C & D) 2. User virt-v2v convert guest to local # virt-v2v -ic xen+ssh://10.66.106.64 -os default xen-hvm-win7-x86_64 -of raw [ 0.0] Opening the source -i libvirt -ic xen+ssh://10.66.106.64 xen-hvm-win7-x86_64 [ 1.0] Creating an overlay to protect the source from being modified [ 1.0] Opening the overlay [ 106.0] Initializing the target -o libvirt -os default [ 106.0] Inspecting the overlay [ 112.0] Checking for sufficient free disk space in the guest [ 112.0] Estimating space required on target for each disk [ 112.0] Converting Windows 7 Ultimate to run on KVM virt-v2v: warning: there are no virtio drivers available for this version of Windows (6.1 x86_64 Client). virt-v2v looks for drivers in /usr/share/virtio-win The guest will be configured to use slower emulated devices. virt-v2v: This guest does not have virtio drivers installed. [ 114.0] Mapping filesystem data to avoid copying unused and blank areas [ 124.0] Closing the overlay [ 124.0] Copying disk 1/2 to /var/lib/libvirt/images/xen-hvm-win7-x86_64-sda (raw) (100.00/100%) [ 427.0] Copying disk 2/2 to /var/lib/libvirt/images/xen-hvm-win7-x86_64-sdb (raw) (100.00/100%) [ 429.0] Creating output metadata Pool default refreshed Domain xen-hvm-win7-x86_64 defined from /tmp/v2vlibvirtbf4507.xml [ 433.0] Finishing off 3. Check the debug log and found: ... libguestfs: trace: umount_all = 0 libguestfs: trace: mount "/dev/sda2" "/" guestfsd: main_loop: proc 47 (umount_all) took 0.00 seconds^M guestfsd: main_loop: new request, len 0x40^M mount -o /dev/sda2 /sysroot/^M libguestfs: trace: mount = 0 libguestfs: trace: fstrim "/" guestfsd: main_loop: proc 1 (mount) took 0.03 seconds^M guestfsd: main_loop: new request, len 0x48^M fsync /dev/sda^M fsync /dev/sdb^M fstrim -v /sysroot/^M /sysroot/: 16 EiB (18446744073709551615 bytes) trimmed^M ^M guestfsd: main_loop: proc 334 (fstrim) took 1.74 seconds^M but in version: libguestfs 1.27.60 libguestfs: trace: mountpoints guestfsd: main_loop: new request, len 0x28^M guestfsd: main_loop: proc 147 (mlibguestfs: trace: mountpoints = ["/dev/sda2", "/"] libguestfs: trace: fstrim "/" ountpoints) took 0.00 seconds^M guestfsd: main_loop: new request, len 0x48^M fsync /dev/sda^M fsync /dev/sdb^M fstrim -v /sysroot/^M /sysroot/: 16 EiB (18446744073709551615 bytes) trimmed^M ^M guestfsd: main_loop: proc 334 (fstrim) took 2.09 seconds^M libguestfs: trace: fstrim = 0 I'm not sure whether it's enough to verify this bug, so rjones please help me confirmed it, thanks.
Created attachment 949350 [details] libguestfs-1.27.60. debug log
Created attachment 949352 [details] libguestfs-1.28.1-1.2 debug log
It is a bit complicated. In the 1.27.60 log (comment 5) you can see: [ 11.0] Mapping filesystem data to avoid copying unused and blank areas libguestfs: trace: mountpoints [...] libguestfs: trace: mountpoints = ["/dev/sda2", "/"] libguestfs: trace: fstrim "/" [...] libguestfs: trace: fstrim = 0 ==> Only /dev/sda2 (C: drive) was trimmed. In the 1.28.1 log (comment 6): libguestfs: trace: mount "/dev/sdb1" "/" [...] libguestfs: trace: mount = 0 libguestfs: trace: fstrim "/" [...] libguestfs: trace: fstrim = 0 [...] libguestfs: trace: mount "/dev/sda2" "/" [...] libguestfs: trace: mount = 0 libguestfs: trace: fstrim "/" [...] libguestfs: trace: fstrim = 0 ==> /dev/sdb1 (D:) and /dev/sda2 (C:) were both trimmed (in reverse order, but that doesn't matter). This bug can be set to VERIFIED based on the information provided.
(In reply to Richard W.M. Jones from comment #7) > It is a bit complicated. In the 1.27.60 log (comment 5) > you can see: > > [ 11.0] Mapping filesystem data to avoid copying unused and blank areas > libguestfs: trace: mountpoints > [...] > libguestfs: trace: mountpoints = ["/dev/sda2", "/"] > libguestfs: trace: fstrim "/" > [...] > libguestfs: trace: fstrim = 0 > > ==> Only /dev/sda2 (C: drive) was trimmed. > > In the 1.28.1 log (comment 6): > > libguestfs: trace: mount "/dev/sdb1" "/" > [...] > libguestfs: trace: mount = 0 > libguestfs: trace: fstrim "/" > [...] > libguestfs: trace: fstrim = 0 > [...] > libguestfs: trace: mount "/dev/sda2" "/" > [...] > libguestfs: trace: mount = 0 > libguestfs: trace: fstrim "/" > [...] > libguestfs: trace: fstrim = 0 > > ==> /dev/sdb1 (D:) and /dev/sda2 (C:) were both trimmed (in reverse > order, but that doesn't matter). > > This bug can be set to VERIFIED based on the information provided. rjones, thanks for your kind help, and according to above comments, move this bug from ON_QA to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0303.html