Bug 852394

Summary:	libguestfs inspection limits registries to 100 MiB
Product:	[Community] Virtualization Tools	Reporter:	Richard W.M. Jones <rjones>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	anande, dyasny, mbooth, sputhenp
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	852396 (view as bug list)		Environment:
Last Closed:	2012-08-29 16:53:26 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:	852396

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.