[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