qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] Add HTTP protocol using curl v2
Date: Wed, 6 May 2009 10:31:43 +0100
User-agent: Mutt/1.4.1i

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

   -drive file=/some/path:with:colons,protocol=file
   -drive file=http://some/path,protocol=uri

For compatability, we could make it such that if protocol=XXX was left out,
it could try and "guess" it, in same way QEMU does if format=XXX is left out
for content format.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]