[Engine-devel] Proposal for support ISO domain on other types of file based storage.

[Mark Wu]

On 03/18/2013 03:11 PM, Shu Ming wrote:
> 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.
I think this problem could be avoided by using VM template. It will 
significantly reduce the number of access on remote ISO images.
>
>>
>>>
>>> [1] http://httpfs.sourceforge.net/
>>>
>>>>
>>>>
>>>> Mark.
>>>>
>>>> [1] http://gerrit.ovirt.org/#/c/12687/
>>>> [2] http://gerrit.ovirt.org/#/c/12916/
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
>