Michael , Did you reach a conclusion yet ?

well, after struggling xsd schema compatibility issues for a while, i came to conclusion that only possible way to implement this feature in a generic way is:

--<type>.<collection_obj>.<collection> "<collection_item>.<coll_item_prop>=val"

for instance:

create host --power_management-options-option "option.name=n1,option.value=v1" --power_management-options-option "option.name=n2,option.value=v2"

It is working, however we have a bug there, it can work in both was:
1) --os-boot boot.dev=hd
2) --os-boot dev=hd

Please take a look:

[RHEVM shell (connected)]# create vm  --description 'Test VM LOCA' --cluster-name Default --name 'restvm_LOCAL' --display-type 'spice' --display-monitors 1 --type 'desktop' --template-id '00000000-0000-0000-0000-000000000000' --memory 1073741824 --os-boot boot.dev=hd --os-type 'unassigned' --cpu-topology-cores 1 --cpu-topology-sockets 1

id                        : 12d568b1-46c8-4205-8f92-d8723964dd87
name                      : restvm_LOCAL
description               : Test VM LOCA
cluster-id                : 99408929-82cf-4dc7-a532-9d998063fa95
cpu-topology-cores        : 1
cpu-topology-sockets      : 1
creation_time             : 2012-09-20T13:50:59.809+03:00
display-allow_reconnect   : False
display-monitors          : 1
display-type              : spice
high_availability-enabled : False
high_availability-priority: 0
memory                    : 1073741824
memory_policy-guaranteed  : 1073741824
origin                    : rhev
os-boot-dev               : hd
os-type                   : unassigned
placement_policy-affinity : migratable
quota-id                  : 00000000-0000-0000-0000-000000000000
stateless                 : False
status-state              : down
template-id               : 00000000-0000-0000-0000-000000000000
type                      : desktop
usb-enabled               : False

[RHEVM shell (connected)]# create vm  --description 'Test VM LOCA' --cluster-name Default --name 'restvm_LOCAL1' --display-type 'spice' --display-monitors 1 --type 'desktop' --template-id '00000000-0000-0000-0000-000000000000' --memory 1073741824 --os-boot dev=hd --os-type 'unassigned' --cpu-topology-cores 1 --cpu-topology-sockets 1

id                        : 5081a5b9-cf14-498d-9796-cafeeba1a43e
name                      : restvm_LOCAL1
description               : Test VM LOCA
cluster-id                : 99408929-82cf-4dc7-a532-9d998063fa95
cpu-topology-cores        : 1
cpu-topology-sockets      : 1
creation_time             : 2012-09-20T13:51:16.357+03:00
display-allow_reconnect   : False
display-monitors          : 1
display-type              : spice
high_availability-enabled : False
high_availability-priority: 0
memory                    : 1073741824
memory_policy-guaranteed  : 1073741824
origin                    : rhev
os-boot-dev               : hd
os-type                   : unassigned
placement_policy-affinity : migratable
quota-id                  : 00000000-0000-0000-0000-000000000000
stateless                 : False
status-state              : down
template-id               : 00000000-0000-0000-0000-000000000000
type                      : desktop
usb-enabled               : False

[RHEVM shell (connected)]#

(In reply to comment #10)
> It is working, however we have a bug there, it can work in both was:
> 1) --os-boot boot.dev=hd
> 2) --os-boot dev=hd
> 

Ilia, 

1. this bug about changing collection based options format

2. as i've mentioned in Comment 7, #2 not always will work because of 
   api schema consistency issues, therefore formal format is #1

Correction: Comment 8, not 7

so should i open another bug for it?

(In reply to comment #13)
> so should i open another bug for it?

i'm not sure this is a bug, just this object assignable from property=value,
format, since we do not obligate supporting this format, it doesn't sound bad,
let Simon to decide on this.

(In reply to comment #14)
> (In reply to comment #13)
> > so should i open another bug for it?
> 
> i'm not sure this is a bug, just this object assignable from property=value,
> format, since we do not obligate supporting this format, it doesn't sound
> bad,
> let Simon to decide on this.


(In reply to comment #10)
> It is working, however we have a bug there, it can work in both was:
> 1) --os-boot boot.dev=hd
> 2) --os-boot dev=hd
> 

I actually like #2 since it makes more sense, however as Michael indicated, it may not always work. If #1 is the correct and only option that always works, then we should block 2. Otherwise we'll get support cases of people complaining about inconsistency and require that #2 should be supported. 

Please clone this one and change title accordingly. This RFE is fulfilled and the #1 vs #2 is a bug. No even high priority since in documentation only the proper format will appear.

bug 859684 opened for this issue as clone of this bug