RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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

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
Note You need to log in before you can comment on or make changes to this bug.