Bug 1811539 - The virt-diff command doesn't work on windows 2019 image
Summary: The virt-diff command doesn't work on windows 2019 image
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libguestfs
Version: 8.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Richard W.M. Jones
QA Contact: YongkuiGuo
URL:
Whiteboard:
Depends On:
Blocks: 1840119 1840120
TreeView+ depends on / blocked
 
Reported: 2020-03-09 07:34 UTC by YongkuiGuo
Modified: 2020-11-04 02:54 UTC (History)
3 users (show)

Fixed In Version: libguestfs-1.40.2-23.module+el8.3.0+6765+441d2340
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1840119 (view as bug list)
Environment:
Last Closed: 2020-11-04 02:53:06 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
The entire virt-diff log (234.86 KB, text/plain)
2020-03-09 07:34 UTC, YongkuiGuo
no flags Details

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 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


Note You need to log in before you can comment on or make changes to this bug.