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

[Anthony Liguori]

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, address@hidden wrote:
> > >       
> > > > From: Alexander Graf <address@hidden>
> > > >
> > > > 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