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

[Charles Duffy]

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:


- Add a temporary file as a disk to the guestfs session on startup; 
within the guest, create a new filesystem there, transfer temporary 
files to it, and delete when done.

Pro: No external dependencies.
Con: Not sure of a safe and correct way to find the name of the 
temporary disk [to ensure that the mkfs operation being scripted refers 
only to it], particularly when trying to script everything into a single 
guestfish invocation with a variable number of other disks exposed (ie. 
using a command line generated by virt-inspect). Upload needs to be 
file-by-file (or have everything bundled in a tarball beforehand).


- Run a tmpfs mount on the guest; upload RPMs there.

Pro: Fast. No need to worry about device names.
Con: Potential for running out of memory. Upload needs to be 
file-by-file (or have everything bundled in a tarball beforehand).


- Stuff the files to be added into a cramfs filesystem, running mkcramfs 
on the host.

Pro: Relatively fast. Easy to transfer a full directory structure to the 
guest at one stroke.
Con: Device names an issue. Requires cramfs.ko to be added to the 
whitelist in appliance/update-initramfs.sh.in.


- Support a FUSE-based mechanism for exporting files, ie. 
ccgfs-over-vmchannel

Pro: Potential to be the cleanest approach from an end-user perspective.
Con: Implementation difficulty; no Fedora or EPEL packages are available 
for ccgfs.