From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1grQ-0003mx-Go for qemu-devel@nongnu.org; Wed, 06 May 2009 09:08:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1grN-0003kb-0i for qemu-devel@nongnu.org; Wed, 06 May 2009 09:08:32 -0400 Received: from [199.232.76.173] (port=50242 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1grM-0003kQ-Js for qemu-devel@nongnu.org; Wed, 06 May 2009 09:08:28 -0400 Received: from qw-out-1920.google.com ([74.125.92.145]:61884) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1grM-0000MG-7X for qemu-devel@nongnu.org; Wed, 06 May 2009 09:08:28 -0400 Received: by qw-out-1920.google.com with SMTP id 4so57720qwk.4 for ; Wed, 06 May 2009 06:08:27 -0700 (PDT) Message-ID: <4A018BC8.8040206@codemonkey.ws> Date: Wed, 06 May 2009 08:08:24 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add HTTP protocol using curl v2 References: <1241571650-16212-1-git-send-email-alex@csgraf.de> <20090506082810.GB23167@redhat.com> <4A0154E9.7020705@redhat.com> <20090506093143.GC23167@redhat.com> In-Reply-To: <20090506093143.GC23167@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , alex@csgraf.de, nolan@sigbus.net, qemu-devel@nongnu.org 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 >>>> >>>> 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