On Mon, 2014-03-17 at 11:22 +0000, Richard W.M. Jones wrote:
[A shared filesystem sounds like what you want, but given that qemu
only has 9pfs and the KVM team have deemed that this is unsupportable,
read on ...]
On Sun, Mar 16, 2014 at 07:17:00PM -0400, Robert Locke wrote:
> Yeah, NFS mounting has been a little problematic/inconsistent for me.
>
> Specifics:
>
> 1) My "/content" directory on the hypervisor host has both direct data
> but also a loop mount of an iso. The iso and its mountpoint both reside
> inside /content.
You could export the ISO readonly to multiple guests as a block
device. Put this into the libvirt XML:
<disk type='block' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/path/to/cd.iso' />
<target dev='sdc' bus='virtio-scsi' tray='open'/>
<readonly/>
<shareable/>
</disk>
How often does the non-ISO content change? If it's essentially static
over long periods you could make it into an ISO or squashfs (or
virt-make-fs) and export it to the guests. However this becomes quite
clumsy if the content changes much.
<snip>
Hmmmm... You know I need to take a closer look at all these libguestfs
tools......
virt-make-fs is interesting to me.
There is a Monday morning setup and the information in /content doesn't
change after that setup.
I'm sure I can experiment myself, but I wonder how long virt-make-fs
takes to create, say, a qcow2 copy of the tree of, say, 12GB? This
might be a way around my NFS problems....
--Rob