Bug 1811539

Summary: The virt-diff command doesn't work on windows 2019 image
Product: Red Hat Enterprise Linux 8 Reporter: YongkuiGuo <yoguo>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: YongkuiGuo <yoguo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.3CC: ptoscano, rjones, virt-maint
Target Milestone: rcKeywords: Triaged
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libguestfs-1.40.2-23.module+el8.3.0+6765+441d2340 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1840119 (view as bug list) Environment:
Last Closed: 2020-11-04 02:53:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1840119, 1840120    
Attachments:
Description Flags
The entire virt-diff log none

Description YongkuiGuo 2020-03-09 07:34:03 UTC 
Created attachment 1668600 [details]
The entire virt-diff log

Description of problem:
The virt-diff command doesn't work on windows 2019 image.


Version-Release number of selected component (if applicable):
libguestfs-1.38.4-15.module+el8.2.0+5297+222a20af.x86_64
libguestfs-winsupport-8.2-1.module+el8.2.0+5590+82cd80df.x86_64
qemu-kvm-2.12.0-98.module+el8.2.0+5698+10a84757.x86_64


How reproducible:
100%


Steps:

1. Prepare a Windows Server 2019 image on rhel8.2 host

2.
# virt-inspector -a Win2019-64-hvm.raw
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda2</root>
    <name>windows</name>
    <arch>x86_64</arch>
    <distro>windows</distro>
    <product_name>Windows Server 2019 Standard</product_name>
    <product_variant>Server</product_variant>
    <major_version>10</major_version>
    <minor_version>0</minor_version>
    <windows_systemroot>/Windows</windows_systemroot>
    <windows_current_control_set>ControlSet001</windows_current_control_set>
    <hostname>WIN-HFJMM8K3DD1</hostname>
    <mountpoints>
      <mountpoint dev="/dev/sda2">/</mountpoint>
    </mountpoints>
    <filesystems>
      <filesystem dev="/dev/sda2">
        <type>ntfs</type>
        <uuid>E6B6D14EB6D1203B</uuid>
      </filesystem>
    </filesystems>
    <drive_mappings>
      <drive_mapping name="C">/dev/sda2</drive_mapping>
    </drive_mappings>
    <applications>
      <application>
        <name>winscp3_is1</name>
        <display_name>WinSCP 5.14 beta</display_name>
        <version>5.14 beta</version>
        <install_path>C:\Program Files (x86)\WinSCP\</install_path>
        <publisher>Martin Prikryl</publisher>
        <url>https://winscp.net/</url>
      </application>
    </applications>
  </operatingsystem>
</operatingsystems>

3.
# cp Win2019-64-hvm.raw Win2019-64-hvm-copy.raw

4.
# virt-diff -a Win2019-64-hvm.raw -A Win2019-64-hvm-copy.raw
libguestfs: error: internal_lxattrlist: getxattr: Argument list too long
libguestfs: error: internal_lxattrlist: getxattr: Argument list too long



Actual results:
There are some errors.

Expected results:
No error output.


Additional info:
Comment 1 Richard W.M. Jones 2020-03-09 10:30:28 UTC 
Apparently this error means:

       E2BIG  The  size of the attribute value is larger than the maximum size
              allowed; the attribute cannot be retrieved.  This can happen  on
              filesystems  that  support  very  large attribute values such as
              NFSv4, for example.

I think I'm going to have to get access to this disk image.  Is it possible
you could make the file available somewhere for me to download?
Comment 2 YongkuiGuo 2020-03-09 12:10:38 UTC 
(In reply to Richard W.M. Jones from comment #1)
> Apparently this error means:
> 
>        E2BIG  The  size of the attribute value is larger than the maximum
> size
>               allowed; the attribute cannot be retrieved.  This can happen 
> on
>               filesystems  that  support  very  large attribute values such
> as
>               NFSv4, for example.
> 
> I think I'm going to have to get access to this disk image.  Is it possible
> you could make the file available somewhere for me to download?

I have sent the image location to you by email.
Comment 3 Richard W.M. Jones 2020-03-09 16:30:26 UTC 
Thanks for the image.  Weirdly this fails for me in libguestfs 1.41.8,
but works in libguestfs 1.42.0.  I believe the only difference this might
be caused by is ntfs-3g system compression (bug 1796073).  Still investigating.
Comment 4 Richard W.M. Jones 2020-03-09 16:32:35 UTC 
By the way, an easy way to see the problem is:

$ virt-rescue --ro -a Win2019-64-hvm.img
><rescue> mount /dev/sda2 /sysroot/
><rescue> ls -l '/sysroot/Program Files/Common Files/microsoft shared/MSInfo'

In libguestfs 1.41 or RHEL AV:

ls: cannot access '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe': Input/output error
total 0
drwxrwxrwx 1 root root 0 Sep 15  2018 en-US
-????????? ? ?    ?    ?            ? msinfo32.exe
><rescue> ls -l '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe' 
lrwxrwxrwx 2 root root 25 Feb  4 11:14 '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe' -> 'unsupported reparse point'

In libguestfs 1.42.0:

><rescue> ls -l '/sysroot/Program Files/Common Files/microsoft shared/MSInfo'
total 227
drwxrwxrwx 1 root root      0 Sep 15  2018 en-US
-r-xr-xr-x 2 root root 367104 Feb  4 11:14 msinfo32.exe
Comment 5 Richard W.M. Jones 2020-03-09 16:54:24 UTC 
Sorry IGNORE comment 4, it is wrong.  This does have to do with NTFS
compression, but not in the way I described in the comment above.

In fact the reproducer is below, and this happens on all versions of
libguestfs and ntfs-3g, even with the latest Fedora:

$ virt-rescue --ro -a Win2019-64-hvm.img
><rescue> mount /dev/sda2 /sysroot/
><rescue> getfattr -d '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe' 
/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe: user.WofCompressedData: Argument list too long

Notice the extended attribute which fails is ‘user.WofCompressedData’.
From a comment in the source code to ntfs-3g-system-compression we can
see this is related to NTFS compression:

 * Rather than building it directly into NTFS, Microsoft implemented this new
 * compression mode using the Windows Overlay Filesystem (WOF) filter driver
 * that was added in Windows 8.1.  A system-compressed file contains the
 * following NTFS attributes:
 *
 * - A reparse point attribute in the format WOF_FILE_PROVIDER_REPARSE_POINT_V1,
 *   documented below
 * - A sparse unnamed data attribute, containing all zero bytes, with data size
 *   equal to the uncompressed file size
 * - A data attribute named "WofCompressedData" containing the compressed data
 *   of the file.

Obviously this attribute can be rather large, since it contains the
compressed data of the whole file.

I guess the easiest thing for libguestfs to do is simply ignore this attribute
if we see it.  The various libguestfs xattr APIs probably shouldn't completely fail
when an over-long attribute is seen anyway.
Comment 6 YongkuiGuo 2020-03-10 08:54:04 UTC 
Thanks rjones, it's very clear.
Comment 7 Richard W.M. Jones 2020-03-12 14:45:12 UTC 
Patch posted:
https://www.redhat.com/archives/libguestfs/2020-March/msg00099.html
Comment 8 Richard W.M. Jones 2020-03-16 13:59:57 UTC 
v2 patch posted:
https://www.redhat.com/archives/libguestfs/2020-March/msg00128.html
Comment 9 Richard W.M. Jones 2020-03-30 10:58:48 UTC 
Upstream in:
https://github.com/libguestfs/libguestfs/commit/5c175fe73264bbf1d3ef79bb066dfb6aff902ad1
https://github.com/libguestfs/libguestfs/commit/af8ed266a282bb20882a9ffb611bd64243d19218
https://github.com/libguestfs/libguestfs/commit/c2c11382bbeb4500f3388a31ffd08cfc18b0de40
Comment 12 YongkuiGuo 2020-05-27 12:42:33 UTC 
Verified with package:
libguestfs-1.40.2-23.module+el8.3.0+6765+441d2340.x86_64

Steps:

1.
$ virt-rescue --ro -a Win2019-64-hvm.raw
><rescue> mount /dev/sda2 /sysroot/
><rescue> getfattr -d '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe'

It works well. No error output.

2.
$ cp Win2019-64-hvm.raw Win2019-64-hvm-copy.raw
$ virt-diff -a Win2019-64-hvm.raw -A Win2019-64-hvm-copy.raw

It also works fine without error.
Comment 15 errata-xmlrpc 2020-11-04 02:53:06 UTC 
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 (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), 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://access.redhat.com/errata/RHSA-2020:4676