On Wed, Sep 27, 2006 at 01:16:17PM -0400, Daniel Veillard wrote:
On Wed, Sep 27, 2006 at 07:05:38PM +0200, Karel Zak wrote:
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 ;-)
I would agree that rather than glueing it's better to separate the 2 strings as separate attributes. But should the second be named 'backend' or something more generic like 'subtype'. That's the only slight concern I have but it's probably better to be explicit about and the suggested form is just fine. Let's go for 4/ :-)
Ok, looks like we have total agreement. I'll knock up a patch implementing option #4 and post it for review. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|