Bug 1064927 - wrong boot order when trying to boot from CDROM while using cloud-init
Summary: wrong boot order when trying to boot from CDROM while using cloud-init
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.3
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 3.4.4
Assignee: Shahar Havivi
QA Contact: bugs@ovirt.org
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-13 15:01 UTC by Sven Kieske
Modified: 2014-09-24 08:08 UTC (History)
8 users (show)

Fixed In Version: ovirt-3.5.0-alpha1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-24 08:08:57 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 25245 0 None MERGED engine: Set boot order to more then one CDROM if selected Never
oVirt gerrit 29773 0 ovirt-engine-3.4 MERGED engine: Set boot order to more then one CDROM if selected Never

Description Sven Kieske 2014-02-13 15:01:12 UTC
Description of problem:

if you attach a cd-rom via run once and make it
the primary boot device
and you submit in the same step cloud-init data
the xml file generated by ovirt looks like the following:

both virtual cd roms get attached and show up in the xml
the expected primary boot device shows up as:
<disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
 <target dev='hdc' bus='ide'/>

with no entity (which it should have):

<boot order='1'/>

the cloud-init data shows up as the following:

<disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
   <source file='/var/run/vdsm/payload/934aebfd-7a7b-4c47-91be-97d58fb32b1e.34f0c17686175ad722c3b0a03f3db4d3.img' startupPolicy='optional'/>
      <target dev='hdd' bus='ide'/>
      <readonly/>
      <serial></serial>
      <boot order='1'/>

the hdd gets "boot order='2'"

this results in a wrong boot order:
the vm trys to start from the cloud-init cd rom and fails
and then boots the hdd.


Tested with the following versions:

rpm -qa vdsm
vdsm-4.12.1-4.el6.x86_64

rpm -qa ovirt-engine
ovirt-engine-3.3.2-1.el6.noarch

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
I'm not able to boot from a cd-rom while passing cloud-init data to the vm

Expected results:
I can boot from cd

Additional info:

The bug may be filed against the wrong component, I don't know if ovirt-engine
messes this up or maybe vdsm.
I also do not know if this is a regression as I never tested this before.

Comment 1 Sven Kieske 2014-02-13 15:02:15 UTC
These bugs might be related (somewhat):
https://bugzilla.redhat.com/show_bug.cgi?id=809457
https://bugzilla.redhat.com/show_bug.cgi?id=809733

Comment 2 Itamar Heim 2014-02-16 08:23:40 UTC
Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 3 Michal Skrivanek 2014-02-28 09:35:16 UTC
i's getting too late for 3.4 so this may need to wait for 3.4.z, let's see how investigation goes

Comment 4 Shahar Havivi 2014-03-02 11:19:49 UTC
What does the xml looks like when you boot without the cloud-init?
Can you boot from the cdrom?
From my testing the cdrom doesn't get the boot-order=1 when there is no cloud-init but hte hdd does get boot-order=2

Comment 5 Shahar Havivi 2014-03-02 14:55:26 UTC
This bug is true for VmPayload as well,
The reason is because we are setting the boot order to the first CDROM that is found in the list.

Comment 6 Sandro Bonazzola 2014-03-04 09:29:50 UTC
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 7 Sven Kieske 2014-03-05 09:12:50 UTC
Could this simple patch still get included in 3.4.0 before GA?

Comment 8 Michal Skrivanek 2014-03-05 09:19:07 UTC
it's not yet even in master, and 3.4 RC is out and GA is imminent I don't see it likely. If it really blocks something feel free to bring it up on ovirt weekly

Comment 9 Michal Skrivanek 2014-03-26 16:24:46 UTC
correction - it's MODIFIED in 3.5

Comment 10 Michal Skrivanek 2014-07-09 14:09:16 UTC
by popular demand, let's backport it to 3.4.z :-)

(setting target release)

Comment 11 Michal Skrivanek 2014-07-14 08:05:00 UTC
3.4.3 RC is out so this needs to wait for 3.4.4

Comment 12 Sandro Bonazzola 2014-09-24 08:08:57 UTC
oVirt 3.4.4 has been released.


Note You need to log in before you can comment on or make changes to this bug.