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

Richard W.M. Jones rjones at redhat.com
Fri May 29 06:26:15 UTC 2009


On Thu, May 28, 2009 at 07:19:06PM -0500, Charles Duffy wrote:
> - 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).

Or you could prepare the disk image in advance using a
separate guestfish operation:

http://et.redhat.com/~rjones/libguestfs/recipes.html#tar2vm

When you attach a new disk it has a predictable name, ie. /dev/hda,
/dev/hdb and so on.  If you know that your guest has only one real
disk image, then your prepared image will always be /dev/hdb.

This is what our V2V scripts do in order to upload new RPMs into the
host, although at the moment it's not very well tested.

> - 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).

The amount of memory available is quite limited.

> - 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.

We should add this anyway -- please file a bug in bugzilla.

> - 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.

And the other option would be:

Implement the FTP server!

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v




More information about the Fedora-virt mailing list