On Wed, Aug 29, 2012 at 04:15:31PM +0100, Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=852394 "libguestfs inspection limits registries to 100 MiB"
On the subject of this limit: Before the change, we had this arbitrary 100 MiB limit so that we didn't download arbitrary amounts of data from the guest into /tmp. This is obviously a good thing, but a customer of ours ran into a guest which had a large number of software packages installed and had a > 100 MiB registry hive. After the change, things are a little bit more complex: * If you open a hive for reading, hivex mmaps it into the process map of the daemon. For a normal-sized hive, this effectively demand-loads the hive from disk as required, and since the majority of inspection operations hardly touch the hive, this is potentially more efficient. For a large (or corrupt/malicious) hive, a 32 bit processor will naturally limit the amount that can be mmapped to ~ 1 GB and fail gracefully if it is larger. A 64 bit processor will map just about any hive, but it's only demand-loaded so that doesn't especially matter. * If you open a hive for writing, hivex tries to malloc enough memory to store a complete copy of the hive, and will fail if there is not enough memory. It's likely that it doesn't fail gracefully (because of the implementation of malloc itself) if the hive is huge. Probably this will crash the daemon or appliance. Therefore when opening a hive for writing, it's a good idea to check the size of the hive beforehand to ensure it's reasonable. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top