Bug 852394 - libguestfs inspection limits registries to 100 MiB
Summary: libguestfs inspection limits registries to 100 MiB
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 852396
TreeView+ depends on / blocked
 
Reported: 2012-08-28 11:27 UTC by Richard W.M. Jones
Modified: 2012-08-29 16:53 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
: 852396 (view as bug list)
Environment:
Last Closed: 2012-08-29 16:53:26 UTC
Embargoed:


Attachments (Terms of Use)

Description Richard W.M. Jones 2012-08-28 11:27:20 UTC
Description of problem:

To avoid using arbitrary amounts of disk space on the host,
libguestfs limits the maximum size of a Windows Registry hive
that it will download:

#define MAX_REGISTRY_SIZE    (100 * 1000 * 1000)

Unfortunately one of our customers found a real guest with
a 102760448 registry, and so libguestfs gave an error when
we tried to perform p2v on it:

inspect_os: size of /Windows/System32/config/SOFTWARE is unreasonably large (102760448 bytes) at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 197.
at /usr/bin/virt-v2v line 671

Version-Release number of selected component (if applicable):

libguestfs 1.16.19

How reproducible:

100%

Steps to Reproduce:
1. Find a Windows guest with a huge SOFTWARE hive.  Not sure how
   you could make one, but possibly just appending zero bytes to
   the end of a registry would be OK for testing.
2. Try to inspect it, eg. guestfish -i
3.
  
Actual results:

inspect_os: size of /Windows/System32/config/SOFTWARE is unreasonably large

Expected results:

Should be able to inspect these registries.

Additional info:

4 ways to solve this that I can see:

(1) Increase the static constant in libguestfs code.  This is safe enough
and we should just do this for RHEL 6.

(2) Make the maximum size configurable through the API.  This just pushes
the problem to callers.

(3) Make the size depend somehow on the maximum size of /tmp and other
factors (eg. are we using tmpfs?)

(4) Move the hivex API into the libguestfs API so that the hive is
manipulated by the daemon.  Therefore nothing needs to be downloaded
and the problem goes away, at the cost of rewriting a great deal of
libguestfs code.

(Thanks Matt Booth)

Comment 1 Anand Nande 2012-08-28 13:46:20 UTC
So is there something that can be done in this?

May be Compress registry hives during V2V
and then bloating it again once the VM starts running on RHEV, considering that compressing the registry has its own performance issues
during and while the system is running ?

reference:

* http://libguestfs.org/hivex.3.html
* http://support.microsoft.com/kb/2498915

Comment 2 Richard W.M. Jones 2012-08-28 13:49:01 UTC
(In reply to comment #1)
> So is there something that can be done in this?
> 
> May be Compress registry hives during V2V
> and then bloating it again once the VM starts running on RHEV, considering
> that compressing the registry has its own performance issues
> during and while the system is running ?
> 
> reference:
> 
> * http://libguestfs.org/hivex.3.html
> * http://support.microsoft.com/kb/2498915

Anything that reduces the hive file (specifically
C:\Windows\System32\Config\SOFTWARE) to below 100 MiB will work.  The
MS KB article above looks like one valid way to do this, albeit they
will need WinPE which isn't common or simple software to do it.

Hivex cannot be used for this.

[Made the comments public because they don't contain
customer information]

Comment 4 Richard W.M. Jones 2012-08-29 15:16:10 UTC
Posted upstream:
https://www.redhat.com/archives/libguestfs/2012-August/msg00140.html

Comment 5 Richard W.M. Jones 2012-08-29 16:53:26 UTC
Pushed upstream in libguestfs 1.19.35.


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