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 _______________________________________________ virt mailing list virt@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt
