Bug 1340163 - Provisioning from RHEVM 3.6 template loses template boot sequence
Summary: Provisioning from RHEVM 3.6 template loses template boot sequence
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.5.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.7.0
Assignee: Martin Betak
QA Contact: Ilanit Stein
URL:
Whiteboard: rhev:provision
Depends On:
Blocks: 1343719
TreeView+ depends on / blocked
 
Reported: 2016-05-26 14:50 UTC by ncatling
Modified: 2017-03-20 15:29 UTC (History)
9 users (show)

Fixed In Version: 5.7.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1343719 (view as bug list)
Environment:
Last Closed: 2017-01-11 20:14:58 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)

Description ncatling 2016-05-26 14:50:13 UTC
Description of problem:
Provisioning from RHEVM 3.6 template loses template boot sequence.

Version-Release number of selected component (if applicable):
CFME 5.5.4.1
Red Hat Enterprise Virtualization Manager Version: 3.6.5.3-0.1.el6

How reproducible:


Steps to Reproduce:
1. Create template with second device in boot sequence
2. Deploy new VM from this template (from CF)
3. Second device is missing in newly provisioned VM

Actual results:


Expected results:


Additional info:

Comment 3 Drew Bomhof 2016-07-12 15:17:50 UTC
I was able to build a template with 2 devices in the boot sequence - The first was a PXE network device.  The second - a block device.

<os type="rhel_6x64">
<boot dev="network"/>
<boot dev="hd"/>
</os>


Upon digging into the ovirt gem - I found that there isn't a way for the Disk class to see a device named "network" as the first device list is  - So when listing disks in the template at provisioning - The 1st boot device in this case never gets created.

So I was able to duplicate the issue with 2 boot devices, one not being a harddisk.

I have a couple of other questions regarding the problem in general:

1. If the template in question had 2 block devices (dev="hd") it seems that this bug wouldn't exist? - Are you seeing that in your environment?

2. Looking at the ovirt gem - it seems that the ("network" device being first in the boot order) issue would exist for any version of RHEV and not only 3.6 - Are you seeing that in your environment?

Comment 5 ncatling 2016-08-05 07:33:08 UTC
I have tested the scenarios and through CloudForms, a VM is provisioned without the boot order set in the source template, regardless of number of disks.

Through RHEV, the provisioning of a new VM always includes the template boot order.

Comment 6 Satoe Imaishi 2016-08-29 13:02:00 UTC
Martin, can you please add PR link?

Comment 7 Satoe Imaishi 2016-08-29 13:02:00 UTC
Martin, can you please add PR link?

Comment 8 Martin Betak 2016-08-29 13:25:40 UTC
PR to the ovirt gem: https://github.com/ManageIQ/ovirt/pull/61
Commit that bumps the ovirt gem version to one that includes the above fix: https://github.com/ManageIQ/manageiq/commit/e1009e0ee38e2bf9eac0ed85e26736ddbba4047b

Comment 9 Ilanit Stein 2016-09-11 12:44:41 UTC
Verified on:
rhevm-3.6.8-0.1.el6
CFME-5.7.0.0.20160906172503_12f65cb

Template rhel-guest-image-7.2-20160302.0.x86_64 with Boot sequense
First device: "network"
Second device:"hd"

Provision VM from template from CF side ends up successfully.
VM indeed was created on RHEVM, and also was started.


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