Re: libvirt, libxl and QDISKs

[Jim Fehlig <jfehlig@suse.com>]

Ian Campbell wrote:
> On Thu, 2013-04-25 at 14:22 +0100, Dave Scott wrote:
>   
>> On 25/04/13 13:43, Ian Campbell wrote:
>>     
>>> On Thu, 2013-04-25 at 13:12 +0100, Dave Scott wrote:
>>>       
>>>> On 25/04/13 12:57, Ian Campbell wrote:
>>>>         
>>>>> On Thu, 2013-04-25 at 12:55 +0100, Stefano Stabellini wrote:
>>>>>
>>>>>           
>>>>>> Right, but going back to the original question: if we have in our hands
>>>>>> something that is not vhd, raw or qcow and blktap2 is available,
>>>>>> should we really try to pass it to it?
>>>>>>             
>>>>> That's not quite the original question because in that case it was raw,
>>>>> at least as far as the libxl interface is concerned.
>>>>>
>>>>>           
>>>>>> We do know that blktap2 only handles qcow, qcow2, raw and vhd (and the
>>>>>> implementation of the first two formats is too buggy to be used).
>>>>>>
>>>>>> Thus I think that the answer is pretty obvious here: we should try with
>>>>>> QEMU, whose supported format list is way wider.
>>>>>>             
>>>>> Which I think we do, we only try and use blktap for raw and vhd.
>>>>>           
>>>> As well as the disk format dimension (vhd, qcow2 etc) there's also the
>>>> network disk access protocol (iSCSI, ceph/RBD, sheepdog?). Although both
>>>> blktap/tapdisk can handle raw, alas all the interesting (perhaps I'm
>>>> showing my bias here ;-) disk access protocols are in qemu. So if we
>>>> default to blktap/tapdisk we can only handle raw *files*, whereas if we
>>>> default to qemu we can also do these new fancy things as well.
>>>>         
>>> Remind me why you can't specify backend=qdisk explicitly? Does libvirt
>>> not propagate anything like that?
>>>       
>> I'll give this a go tomorrow when I'm not at the mercy of dodgy wifi :-) 
>>  From my reading of the libvirt code it does allow the selection of a 
>> driverName from the set "tap" "tap2" "file" and "phy".
>>     
>
> In libxl the choices are phy, tap and qdisk. There's no file nor any
> distinction between tap and tap2. I expect the libxl libvirt driver is
> trying to make things easier for people migrating from xend (which is
> to be applauded).
>   

Right.  'file' is mapped to backend 'tap' and format 'raw'.  In fact, I
should just post the code here for review :).  For a bit of context,
l_disk is libvirt's definition, and x_disk is libxl's.  Comments on this
mapping welcome, keeping in mind Ian's point about migrating from xend.

    if (l_disk->driverName) {
        if (STREQ(l_disk->driverName, "tap") ||
            STREQ(l_disk->driverName, "tap2")) {
            switch (l_disk->format) {
            case VIR_STORAGE_FILE_QCOW:
                x_disk->format = LIBXL_DISK_FORMAT_QCOW;
                x_disk->backend = LIBXL_DISK_BACKEND_QDISK;
                break;
            case VIR_STORAGE_FILE_QCOW2:
                x_disk->format = LIBXL_DISK_FORMAT_QCOW2;
                x_disk->backend = LIBXL_DISK_BACKEND_QDISK;
                break;
            case VIR_STORAGE_FILE_VHD:
                x_disk->format = LIBXL_DISK_FORMAT_VHD;
                x_disk->backend = LIBXL_DISK_BACKEND_TAP;
                break;
            case VIR_STORAGE_FILE_NONE:
                /* No subtype specified, default to raw/tap */
            case VIR_STORAGE_FILE_RAW:
                x_disk->format = LIBXL_DISK_FORMAT_RAW;
                x_disk->backend = LIBXL_DISK_BACKEND_TAP;
                break;
            default:
                virReportError(VIR_ERR_INTERNAL_ERROR,
                               _("libxenlight does not support disk
driver %s"),
                              
virStorageFileFormatTypeToString(l_disk->format));
                return -1;
            }
        } else if (STREQ(l_disk->driverName, "file")) {
            x_disk->format = LIBXL_DISK_FORMAT_RAW;
            x_disk->backend = LIBXL_DISK_BACKEND_TAP;
        } else if (STREQ(l_disk->driverName, "phy")) {
            x_disk->format = LIBXL_DISK_FORMAT_RAW;
            x_disk->backend = LIBXL_DISK_BACKEND_PHY;
        } else {
            virReportError(VIR_ERR_INTERNAL_ERROR,
                           _("libxenlight does not support disk driver %s"),
                           l_disk->driverName);
            return -1;
        }
    } else {
        /*
         * If driverName is not specified, default to raw as per
         * xl-disk-configuration.txt in the xen documentation and let
         * libxl pick a suitable backend.
         */
        x_disk->format = LIBXL_DISK_FORMAT_RAW;
        x_disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
    }

>   
>> It looks like we could define a "qdisk" driverName.
>>     
>
> Yes, I think this would work. WRT to your comment below it looks like
> other libvirt drivers call this driver "qemu".
>   

IMO, we should just extend the above to map driverName 'qemu' to backend
'qdisk'.  But what about the formats?  I though qdisk could handle all
of them, particularly with qemu-upstream, even vmdk?

>   
>> Actually this reminds me of a general concern I had: I worry that people 
>> who choose to use libvirt will likely use all the default options, and 
>> not customise their code too much for a specific hypervisor. After all, 
>> if they wanted to customise their code for xen they would just use libxl 
>> and use the richer interface. I think we ought to make sure as much 
>> stuff just works by default as possible. In my ideal world it would be 
>> possible to take a simple libvirt domain configuration (perhaps one 
>> which used to run on kvm) and run it on xen, transparently benefiting 
>> from xen features such as driver domains (and automatic blktap/qemu 
>> selection?). I think if the domain XML requires too much tweaking then 
>> people will just not use the features or may give up altogether.
>>     
>
> This would be ideal, I seem to remember hearing that disk configuration
> was something which libvirt didn't abstract, tending to just expose
> underlying configuration strings of the underlying toolstack. So this is
> one area where you actually have to change things when you migrate
> between hypervisors or they won't work at all.
>   

For the most part, that is true, unless you were using a minimal
configuration and letting the individual hypervisor driver choose
defaults.  It would probably work with raw images and no driver element
defined, e.g.

  <disk type='file' device='disk'>
    <source file='/path/to/disk.raw'/>
    <target dev='hda' bus='ide/>
  </disk>

Regards,
Jim