On Tue, Sep 26, 2006 at 08:08:33PM +0100, Daniel P. Berrange wrote:
>
> This means the easy option of just making all file devices use blktap in
> 3.0.3 is not practical. This in turns means we need to come up with a
> way to express the new driver methods in libvirt XML. There are a few
> options I can think of :
>
> - Allow more values in the 'type' attribute, eg file, block, blktap:aio,
> blktap:qcow, etc. This feels wrong because the blktap:* entries are
> really still 'file' types.
>
> - Introduce a new attribute 'driver' where you can specify 'loop',
> 'blktap:aio', 'blktap:qcow', etc
>
> - Introduce a new element 'driver' where you can specify the same
>
> <disk type="file">
> <driver type='blktap:aio'/>
> </disk>
>
> - Same as above, but normalize the driver type further
>
> <disk type="file">
> <driver type='blktap' backend='aio' />
> </disk>
>
> My preference is probably option 3 or 4.
My preference is definitely 4.
(well, I'm affected by Database Normalization where it's bad merge
two information into one attribute -- so 'blktap:aio' is wrong way
;-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>