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

Re: [libvirt] Curl/HTTP block device

Dne 16.8.2011 20:13, Daniel P. Berrange napsal(a):
On Tue, Aug 16, 2011 at 11:02:23AM -0600, Eric Blake wrote:
On 08/12/2011 04:31 AM, Radek Hladik wrote:
I've noticed newer version of curl in last qemu changelog. It seems that
its needed for curl block device. Unfortunatelly, I was not able to find
out more. I tried to look into qemu source code and to some patches but
I am not much wiser.
As I understand it, qemu could be able to use a curl compatible URL as
block device. Probably only in readonly mode but it still would be very
usefull for i.e. ISO images.
Can anyone point me in the right direction and more importantly, is this
feature available via Libvirt?

I believe you are correct that curl block devices are not yet
supported in libvirt, but patches would be welcome.

We had previously rejected the idea of curl block devices as a crazy
idea, but since we have now accepted config of NBD, Sheepdog, and
other network based block devices, we can't justify leaving out
the curl ones. So any patches for curl block devs are welcome.


I was briefly looking what would it need to create such patch. I've been checking how nbd support is done but then I found out one difference. NBD and sheepdog are providing one driver where CURL provides at least 5:
# ./qemu-kvm-015 -drive format=?
Supported formats: ... nbd sheepdog ... tftp ftps ftp https http
Should libvirt use all these as separate drive types or have one "metatype" i.e. curl? On the other hand I did not find any other argument but the source URL. Actually it could maybe work right away with specifying URL in file attribute for raw device but libvirt complains about non-existing file :-)
What should disk element look like? qemu arguments are quite simple:
-drive file=http://rip.7bf.de/current/RIPLinux-13.5-non-X.iso,if=ide,media=cdrom,boot=on

And lastly, why do you find the idea of curl block device crazy? I think that its very handy solution as long as you understand the limitations (speed is the most important one :-) ). For example on our farm we have problem that if a customer wants to use some installation media or driver disk, we need to download it to shared storage (currently SMB share). Then she can use it in her guest XML definition. This way she just points her guest to use the device right from source URL.


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