Re: [Qemu-devel] [PATCH] Add HTTP protocol using curl v2

[Anthony Liguori <anthony@codemonkey.ws>]

Daniel P. Berrange wrote:
> On Wed, May 06, 2009 at 11:14:17AM +0200, Kevin Wolf wrote:
>   
>> Daniel P. Berrange schrieb:
>>     
>>> On Wed, May 06, 2009 at 03:00:50AM +0200, alex@csgraf.de wrote:
>>>       
>>>> From: Alexander Graf <alex@csgraf.de>
>>>>
>>>> Currently Qemu can read from posix I/O and NBD. This patch adds a
>>>> third protocol to the game: HTTP.
>>>>
>>>> In certain situations it can be useful to access HTTP data directly,
>>>> for example if you want to try out an http provided OS image, but
>>>> don't know if you want to download it yet.
>>>>
>>>> Using this patch you can now try it on on the fly. Just use it like:
>>>>
>>>> qemu -cdrom http://host/path/my.iso
>>>>         
>>> I rather think there should be an explicit flag to allow use of http://
>>> URLs in filenames at runtime, not just 'configure' time. There are many
>>> apps out there using QEMU which will be assuming QEMU treats all disk
>>> paths as local files, and thus not got explicit code to check whether 
>>> a URI is passed. I could well see that some will consider it a security
>>> issue to allow QEMU to download off the net, but if they updated to
>>> a new QEMU with this patch, downloading would be allowed by default.
>>>       
>> If apps want to be sure that they are accessing a local file, they must
>> ensure not to have a colon in the file name. Otherwise this specifies a
>> protocol for the qemu block layer.
>>     
>
> Using paths with a colon in the file name is pretty critical if
> you wish to configure VMs with block devices using a stable path
> like those under /dev/disk/by-path/ - they pretty much all contain
> colons, and are the only good stable path for iSCSI or FibreChannel
> block devices.
>
>   
>> Btw, we could use a way to escape colons in a file name. Using such
>> files isn't possible currently.
>>
>>     
>>> Perhaps only enable these remote URIs with the -drive parameter, when
>>> an explicit fmt=http option is set. But can this be layered into the
>>> other protocols, eg could the remote URI be in qcow, vmdk, etc formats,
>>> or are you assuming the remote uri is raw file ?
>>>       
>> It should work with all formats. This is why fmt=http is wrong. It's not
>> a format, but a protocol.
>>     
>
> Then I'd prefer we add a protocol=XXX option for magic protocols. This 
> would be easier to use & clearer than requiring escaping of magic 
> characters, eg
>   

It just exacerbates the problem.  The comma is also a special character 
so now to avoid problems with ':' as a special character, you're relying 
on another special character.

We absolutely need escaping.  I have no doubt about that.

 From a human readable perspective though, I think we could introduce a 
"file:" protocol which ensured that we used a local file protocol.  For 
instance,

 -drive file=file:/some/path

Regards,

Anthony Liguori