[fedora-virt] libguestfs best practices: Exposing files from the host for the duration of a session

[Charles Duffy]

Michael Ansel wrote:
> On Thu, May 28, 2009 at 8:19 PM, Charles Duffy <charles at dyfis.net> wrote:
>   
>> I have a rather large set of RPMs and such on my host I want to install on
>> my guest using libguestfs. The normal way to do this would be to upload the
>> package(s), install them, then (optionally) remove the RPMs.
>>
>> However, I don't particularly want to bloat the qcow2 file with the changes
>> made via uploading files which are only going to be deleted when no longer
>> in use. Someday (*sigh*) we'll have 9p-over-virtio support built into qemu;
>> until then, a few ways to get around this present themselves:
>>     
>
> What about setting up a temporary NFS export on the host and mounting
> that on the guest? I've done installs using yum/rpm directly from the
> NFS mount, eliminating the need to ever copy the RPMs into anything
> more than working memory. If network security is an issue, I'm sure
> you could use a combination of iptables rules and NFS export options
> to limit access to that single box as well (though, I haven't done
> that one).
As libguestfs (and the software I'm building with it) runs unprivileged 
and unattended, an added requirement of NFS server support on the host 
would mean a pretty massive increase in security exposure and 
administrative load. (Also, the libguestfs appliance doesn't included 
nfs-utils at present, and I don't know that NFS works over qemu's 
SLiRP-based "-net user" mode anyhow).

If I were going to go that route, I'd probably lean towards using qemu's 
existing SMB server support -- but there would still be changes to the 
guest needed, making it less than pain-free.

[For the moment, I ended up using squashfs; cramfs, mentioned in my 
previous email, was a Really Bad Idea on account of the size limitations]