Also this bug regarding boot order with cloud init might be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1064927
Am 20.08.2014 16:20, schrieb Omer Frenkel: > > > ----- Original Message ----- >> From: "Omer Frenkel" <[email protected]> >> To: "Jorick Astrego" <[email protected]> >> Cc: [email protected] >> Sent: Wednesday, August 20, 2014 2:16:25 PM >> Subject: Re: [ovirt-users] vm install via iso - optical drive eject >> behaviour? >> >> >> >> ----- Original Message ----- >>> From: "Jorick Astrego" <[email protected]> >>> To: [email protected] >>> Sent: Wednesday, August 20, 2014 12:53:56 PM >>> Subject: Re: [ovirt-users] vm install via iso - optical drive eject >>> behaviour? >>> >>> >>> On 08/20/2014 11:21 AM, Omer Frenkel wrote: >>> >>> >>> >>> ----- Original Message ----- >>> >>> >>> >>> From: "Paul Jansen" <[email protected]> To: "users" <[email protected]> >>> Sent: >>> Tuesday, August 19, 2014 2:25:41 PM >>> Subject: [ovirt-users] vm install via iso - optical drive eject behaviour? >>> >>> Hello. >>> I currently have oVirt 3.4.x set up. >>> A colleague mentioned that he was having an issue where booting a VM with >>> an >>> attached iso and installing via cd/dvd does not allow the contents of the >>> 'drive' to eject after the install. Sure enough, I have tested this myself >>> and observed the same behaviour. >>> Installing an EL/fedora iso image with a kickstart that has a 'reboot >>> --eject' line in will eject the 'drive' after the installing when doing the >>> exact same thing on VMware ESXi (and 'real' hardware). >>> A suggestion was made that VMware emulates a laptop style optical drive >>> that >>> once the disk ejects the system cannot close the drive bay upon reboot - >>> this is a manual operation. >>> Does oVirt emulate a destop style drive where even if the disk is ejected, >>> when a reboot occurs the drive will close? >>> >>> The long an short of this that even though the 'reboot --eject' option is >>> in >>> the kickstart, the iso image seems be be reattached when the VM reboots and >>> the installs process starts again. An infinite loop effectively. >>> >>> I'm told this isn't an issue with an KVM/Qemu VM under virt-manager. >>> >>> Any suggestions as to how to solve this? >>> I should point out that I cannot simply extract files and boot via PXE as >>> this process is supposed to be testing an install process via generated >>> media. >>> >>> Thanks. >>> there is an open RFE for detecting the reboot and eject the cd in run once. >>> >>> until that, what i do is: (assuming the HD doesn't have anything bootable >>> on >>> it) >>> edit the vm, >>> select in 'boot options': >>> first device- hard disk, >>> second device-CD and select the CD file you want to use. >>> >>> start the vm regularly (not run once) >>> Does this work for you? >>> >> >> interesting, i just installed one vm and it worked for me yesterday, >> and i tried again now couple of times (to be sure) and i see the same issue. >> >> trying to investigate now what is the difference >> > > ok found the issue, there is a bug in add disk that cause the boot order to > be wrong (order is calculated before the disk is added). > looks like this affects vms created from blank (or other diskless) template > and the disk is added afterwards > while this is fixed, a workaround is to first create the vm and the disk, > and only after that, edit the vm and choose the wanted boot options, this > will cause the boot order to be re-calculated, taking into account also the > disk. > > if your vm already created, you can edit the boot order to something and then > return it to what you like. > >>> In 3.5rc1, I have the following issue: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1131018 >>> >>> >>> >>> >>> Description of problem: >>> Installing a VM with the Second Boot device CDROM. After installation, I >>> choose reboot in the VM and the installer of the CDROM appears again even >>> though I have the HDD as first boot device. >>> >>> When I power down the VM, don't change anything, and power it up again. It >>> does start from the local HDD >>> Kind regards, >>> >>> Jorick Astrego >>> Netbulae >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > > > -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
