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

Bug 907294

Summary: VM does not respect the boot order defined in oVirt Engine Web UI
Product: [Retired] oVirt Reporter: Zhou Zheng Sheng <zhshzhou>
Component: vdsmAssignee: Mooli Tayer <mtayer>
Status: CLOSED WORKSFORME QA Contact: Haim <hateya>
Severity: unspecified Docs Contact:
Priority: high    
Version: 3.2CC: abaron, acathrow, bazulay, iheim, jkt, mgoldboi, michal.skrivanek, yeylon, zhshzhou
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-09 18:19:54 UTC 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:
Attachments:
Description Flags
Start the VM two times, with the boot squence to hard disk first. The first time I attach an ISO image to it, the second time without the image. The tarball contains the extacted log, paras, XML none

Description Zhou Zheng Sheng 2013-02-04 03:44:53 UTC
Created attachment 692590 [details]
Start the VM two times, with the boot squence to hard disk first. The first time I attach an ISO image to it, the second time without the image. The tarball contains the extacted log, paras, XML

Description of problem:
In the VM creation and edit Web UI in oVirt Engine, we can select the boot Sequence. The VM created by VDSM does not respect it. The created VM always boot from cdrom before hard disk.

Version-Release number of selected component (if applicable):
oVirt 3.2
# rpm -qa | grep ovirt
ovirt-engine-sdk-3.2.0.5-1.20121213.gitc0ab704.fc18.noarch
ovirt-image-uploader-3.1.0-1.fc18.noarch
ovirt-log-collector-3.1.0-1.fc18.noarch
ovirt-engine-config-3.2.0-2.fc18.noarch
ovirt-engine-webadmin-portal-3.2.0-2.fc18.noarch
ovirt-engine-dbscripts-3.2.0-2.fc18.noarch
ovirt-engine-tools-common-3.2.0-2.fc18.noarch
ovirt-engine-notification-service-3.2.0-2.fc18.noarch
ovirt-host-deploy-1.0.0-0.1.beta.fc18.noarch
ovirt-engine-setup-3.2.0-2.fc18.noarch
ovirt-engine-cli-3.2.0.7-1.20121212.gitd77dad3.fc18.noarch
ovirt-engine-backend-3.2.0-2.fc18.noarch
ovirt-engine-3.2.0-2.fc18.noarch
ovirt-engine-restapi-3.2.0-2.fc18.noarch
ovirt-host-deploy-java-1.0.0-0.1.beta.fc18.noarch
ovirt-engine-genericapi-3.2.0-2.fc18.noarch
ovirt-engine-userportal-3.2.0-2.fc18.noarch
ovirt-iso-uploader-3.1.0-1.fc18.noarch

vdsm 4.10.3
# rpm -qa | grep vdsm
vdsm-python-4.10.3-6.fc18.x86_64
vdsm-4.10.3-6.fc18.x86_64
vdsm-cli-4.10.3-6.fc18.noarch
vdsm-xmlrpc-4.10.3-6.fc18.noarch

How reproducible:
Always

Steps to Reproduce:
1. Create a VM in oVirt Engine Web UI
2. Install OS to guest's disk
3. Shutdown the VM. Set the boot sequence to hard disk first, cdrom second. Set the hard disk to bootable. Attach a bootable ISO image to the cdrom
3. Start the VM
  
Actual results:
The VM boots from cdrom.

Expected results:
The VM boots from the hard disk.


Additional info:
I create a VM with a bootable disk and set boot sequence to hard disk first. Then I boot it with an cdrom ISO image attached, it boots from the cdrom. The second time I boot it without an ISO image, it boots from the hard disk.

From the VDSM log I can see the VM creation parameters that VDSM gets from Engine and the VM XML definition that VDSM sends to libvirt. In the VM parameter dict, Engine specify an IDE controller device under the 'custom' key. The bootOrder of this controller is set to 0. Then bootOrder of the cdrom device is set to 1. However in the output XML definition file, only the cdrom device gets a "<boot order="1"/>", and no boot order XML element for the hard disk device. Then libvirt starts the qemu with a bootindex=1 to cdrom.

The second time I boot the VM without an ISO image, the result VM parameter dict and XML definition are almost the same as the first time, only the ISO image path is removed. The virtual machine failed to read the ISO image, so it boots from the hard disk.

After having a look at VDSM code, I find the bootOder is proccessed for cdrom/hard drives but not IDE controller. This may be the problem. If VDSM sees the bootOrder in an IDE controller, it should apply the bootOder to every drive attached to the controller.

Comment 1 Michal Skrivanek 2013-08-20 09:07:40 UTC
can you try again? It may have been fixed relatively recently in engine. As per Arik it works now (and it indeed didn't before)

Comment 2 Itamar Heim 2013-12-09 18:19:54 UTC
no reply since august, closing. please re-open if reproduces on latest.

Comment 3 Red Hat Bugzilla 2023-09-14 01:41:04 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days