Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 921464

Summary: rhevm-cli: --vm-os-boot doesn't send the order of devices
Product: Red Hat Enterprise Virtualization Manager Reporter: Jakub Libosvar <jlibosva>
Component: ovirt-engine-cliAssignee: Ravi Nori <rnori>
Status: CLOSED CURRENTRELEASE QA Contact: Katarzyna Jachim <kjachim>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: acathrow, bdagan, dyasny, iheim, mpastern, ncredi, oramraz, Rhev-m-bugs, sgrinber, talayan, ykaul
Target Milestone: ---Keywords: Regression
Target Release: 3.2.0Flags: sgrinber: Triaged+
Hardware: All   
OS: Linux   
Whiteboard: virt
Fixed In Version: sf13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jakub Libosvar 2013-03-14 09:28:15 UTC
Description of problem:
When starting vm with parameter --vm-os-boot "boot.dev=hd,boot.dev=network" only network device is sent:
<os>
    <boot dev="network"/>
</os>

Version-Release number of selected component (if applicable):
rhevm-cli-3.2.0.5-1.el6ev.noarch

How reproducible:
Always

Steps to Reproduce:
1. Start vm once with --vm-os-boot "boot.dev=hd,boot.dev=network"
2.
3.
  
Actual results:
<os>
    <boot dev="network"/>
</os>

Expected results:
<os>
    <boot dev="hd"/>
    <boot dev="network"/>
</os>

Additional info:
I will update whether it's a regression against 3.1 after I try it on 3.1

Comment 1 Michael Pasternak 2013-03-14 10:19:32 UTC
(In reply to comment #0)
> Description of problem:
> When starting vm with parameter --vm-os-boot "boot.dev=hd,boot.dev=network"

Jakub,

the option name is --os-boot and not --vm-os-boot, even if this is still
working in 3.2, it will be broken by 39aa5ef in 3.3, please use help/auto-
completion to see available options.

Comment 3 Michael Pasternak 2013-03-14 13:11:53 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > When starting vm with parameter --vm-os-boot "boot.dev=hd,boot.dev=network"
> 
> Jakub,
> 
> the option name is --os-boot and not --vm-os-boot, even if this is still
> working in 3.2, it will be broken by 39aa5ef in 3.3, please use help/auto-
> completion to see available options.

slight misunderstanding, i was sure that you trying to add vm, in any case
actions receive an <action> object and one of the parameters in it is <vm>, 
so you need to say --vm-x-y, --x will set x directly to action, i.e action.x,

while /add receive an object you wish to create, so since you already in context
of vm, there is no need repeating it,

bottom line you're alright.

Comment 4 Michael Pasternak 2013-03-24 09:51:04 UTC
*** Bug 923806 has been marked as a duplicate of this bug. ***

Comment 5 Michael Pasternak 2013-03-24 12:38:42 UTC
*** Bug 922815 has been marked as a duplicate of this bug. ***

Comment 6 Oded Ramraz 2013-03-24 12:54:25 UTC
Michael , 

In general it is better to have separate bug per use case .
We mark bug as duplicate only if is exactly the same use case / exception e.t.c 
This bug is about boot order while Bug 922815 is about missing PM field. I don't see how they are duplicates . 
It also makes the verification process more complicated and someone might neglect the PM use case when he verify this busy . 



(In reply to comment #5)
> *** Bug 922815 has been marked as a duplicate of this bug. ***

Comment 7 Michael Pasternak 2013-03-24 12:58:25 UTC
(In reply to comment #6)
> Michael , 
> 
> In general it is better to have separate bug per use case .
> We mark bug as duplicate only if is exactly the same use case / exception
> e.t.c 
> This bug is about boot order while Bug 922815 is about missing PM field. I
> don't see how they are duplicates . 

both are caused by same bug (i've mentioned this is the closed BZ), but i
don't mind you reopening it if this will make easer for you to track the
issue.

Comment 9 Katarzyna Jachim 2013-04-09 13:49:27 UTC
verified on rhevm-cli-3.2.0.6-1.el6ev.noarch, works ok

Comment 10 Itamar Heim 2013-06-11 09:38:48 UTC
3.2 has been released

Comment 11 Itamar Heim 2013-06-11 09:38:56 UTC
3.2 has been released

Comment 12 Itamar Heim 2013-06-11 09:52:50 UTC
3.2 has been released