xl block-attach

xl block-attach

[Kamala Narasimhan]

The format in which disk information is required in xl block-attach is different
than the one expected in the disk configuration option (in the config file).  It
might make sense to keep the two consistent (excluding the domain/backend dom id
additional param block-attach would require).  Would it be alright if I enforce
it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify
block-attach help to reflect that change?

Kamala

Re: xl block-attach

[Ian Campbell]

On Sun, 2011-01-30 at 19:56 +0000, Kamala Narasimhan wrote:
> The format in which disk information is required in xl block-attach is different
> than the one expected in the disk configuration option (in the config file).  It
> might make sense to keep the two consistent (excluding the domain/backend dom id
> additional param block-attach would require).  Would it be alright if I enforce
> it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify
> block-attach help to reflect that change?

I think it makes sense to have them be the same (or as similar as
possible).

OOI, do the xm block-attach and xm config syntaxes differ from each too?

Ian.

Re: xl block-attach

[Kamala Narasimhan]

Ian Campbell wrote:
> On Sun, 2011-01-30 at 19:56 +0000, Kamala Narasimhan wrote:
>> The format in which disk information is required in xl block-attach is different
>> than the one expected in the disk configuration option (in the config file).  It
>> might make sense to keep the two consistent (excluding the domain/backend dom id
>> additional param block-attach would require).  Would it be alright if I enforce
>> it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify
>> block-attach help to reflect that change?
> 
> I think it makes sense to have them be the same (or as similar as
> possible).
> 
> OOI, do the xm block-attach and xm config syntaxes differ from each too?
> 

I think so.  The disk config syntax passed to xm through a config file is
different than xm block-attach syntax.

Kamala

Re: xl block-attach

[Ian Campbell]

On Mon, 2011-01-31 at 15:10 +0000, Kamala Narasimhan wrote:
> Ian Campbell wrote:
> > On Sun, 2011-01-30 at 19:56 +0000, Kamala Narasimhan wrote:
> >> The format in which disk information is required in xl block-attach is different
> >> than the one expected in the disk configuration option (in the config file).  It
> >> might make sense to keep the two consistent (excluding the domain/backend dom id
> >> additional param block-attach would require).  Would it be alright if I enforce
> >> it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify
> >> block-attach help to reflect that change?
> > 
> > I think it makes sense to have them be the same (or as similar as
> > possible).
> > 
> > OOI, do the xm block-attach and xm config syntaxes differ from each too?
> > 
> 
> I think so.  The disk config syntax passed to xm through a config file is
> different than xm block-attach syntax.

What are the syntaxes and how are they different? I was under the
impression that (roughly speaking) the comma separated stuff in the
config file simply became the individual arguments to block-attach, is
that not the case?

Ian.

Re: xl block-attach

[Kamala Narasimhan]

Ian Campbell wrote:
> On Mon, 2011-01-31 at 15:10 +0000, Kamala Narasimhan wrote:
> What are the syntaxes and how are they different? I was under the
> impression that (roughly speaking) the comma separated stuff in the
> config file simply became the individual arguments to block-attach, is
> that not the case?
>

Kind of but not quite.

Here is what I get from block-attach help (both xl/xm return the same btw) -

*********

Usage: xl [-v] block-attach <Domain> <BackDev> <FrontDev> [<Mode>] [BackDomain]

Create a new virtual block device.

*********

>From the above it is not very evident what is acceptable for BackDev and
FrontDev.  So I looked at the code that parses these input (in xl).  It takes
backdev and looks for pdev type ('phy' or 'file' or 'tap') and if tap, looks for
'aio' or 'vhd' or 'qcow' or 'qcow2' (here it is mixing format with backend impl
type) followed by pdev path.    It then takes frontdev and interprets it to be
vdev path and then it interprets mode to be read or write attribute.

We could still keep the higher level arguments as is but our parser could
interpret BackDev and FrontDev values the way it does for config file option.
The way I have refactored the disk config parsing code (by dividing it into
pdev/vdev/attrib chunks for parsing, we can simply reuse that parsing code in
block-attach too!

Kamala

Re: xl block-attach

[Ian Campbell]

On Mon, 2011-01-31 at 16:45 +0000, Kamala Narasimhan wrote:
> From the above it is not very evident what is acceptable for BackDev
> and FrontDev.  So I looked at the code that parses these input (in
> xl).  It takes backdev and looks for pdev type ('phy' or 'file' or
> 'tap') and if tap, looks for 'aio' or 'vhd' or 'qcow' or 'qcow2' (here
> it is mixing format with backend impl type) followed by pdev path.
> It then takes frontdev and interprets it to be vdev path and then it
> interprets mode to be read or write attribute.

Possible implementation bugs and lack of code reuse aside it sounds as
if the intention was to support the same stuff as the configuration
file.

> We could still keep the higher level arguments as is but our parser
> could interpret BackDev and FrontDev values the way it does for config
> file option. 

That sounds sensible to me.

Ian.