----- Original Message ----- > > On 03/18/2013 04:43 PM, Ayal Baron wrote: > > > ----- Original Message ----- > > Mark Wu : > > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > > ----- Original Message ----- > > Hi guys, > > Currently, ISO domain is only supported on NFS storage. It could > improve the ease of use if it allows other types > of file based storage to store ISO images. After an > investigation, I > found there's not any restriction on this idea. > So the whole work is removing the limitation on engine side. That > means engine should allow ISO domain could > have different storage type from the data center it's attached, > like > what we do with nfs ISO domain in SAN DC. > > I start this idea with localfs. I know local storage can't be > seen in > cluster level. But it also provides a choice if no > NFS available. VMs can be created on the host which has the ISO > repo, > and then be migrated to any other host in the cluster. > I have done the initial patches: allow creation ISO domain on > localfs > [1] and support import ISO domain on localfs [2] > I don't have much experience in java/j2ee/web development and > engine > architecture. The patches just work for me. > I am not sure if it will bring some potential problems. So any > feedback on the patch or the idea will be appreciated very much. > Haven't looked at the patches yet, but wrt the idea, I agree on > the > need (being able to attach ISOs from anywhere and not just nfs) > but I > think the way to do this should be by getting rid of the ISO > domain > type altogether. I think ISO domain on localfs is useful for a simple > setup or demo, > such as oVirt all-in-one. > > Basically what we need is: > 1. a way to connect to file based storage (let's leave block aside > for now) - this already exists via the connectStorageServer verb > 2. a way to list and present a file system tree in gui (give an > arbitrary path to vdsm and list content) and possibly filter > results > by type (vfd, iso) - does not exist today. Possibly some security > aspects here that need hashing out. > 3. a way to specify a path to a file when attaching an iso/vfd to > a > VM - this is the way it works today > > This would devoid the need for isoUploader and allow users to > simply > manage an nfs export with files. > Next step would be to make connectStorageServer support httpfs [1] > and then we'd be able to mount ISOs directly over http (hopefully > this would be sufficient to support ISOs stored on S3, swift, > glance, > etc). Actually, we could use the qemu curl backend image support > directly. > That means we don't need mount the place storing ISO images. We can > just maintain a list of ISO image with its link, which could be > http, > ftp and ssh. That will be fine to start a VM on a existing extern ISO > image. I > also > would like to maintain a ISO image cache on the local host to avoid > to > re-streaming the ISO image from the ISO image repositories every > time. > That will be helpful for people who is suffered from the network > bottleneck. We have a similar requirement for glance support (not > limited to ISOs, rather to all read-only images) so that should be > tackled with a broader solution. In that case, I suppose qemu's > copy-on-read + httpfs (you mentioned above) could help. It can avoid > accessing the same backing file sectors repeatedly. > But the copied content can't be shared by multiple VM using the same > backend image.
Sounds like an rfe for qemu. Basically we need to try and split the storage part in qemu to a separate process to enable such capabilities. > > > > > > > > > > [1] http://httpfs.sourceforge.net/ > > Mark. > > [1] http://gerrit.ovirt.org/#/c/12687/ [2] > http://gerrit.ovirt.org/#/c/12916/ > _______________________________________________ > Engine-devel mailing list [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel -- > --- > 舒明 Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: [email protected] or > [email protected] Address: 3/F Ring Building, ZhongGuanCun > Software Park, Haidian > District, Beijing 100193, PRC > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
