Bug 1054070

Summary: [RFE] add ability to cold restart of a VM when it run by Run Once and reboots
Product: [oVirt] ovirt-engine Reporter: Sven Kieske <s.kieske>
Component: RFEsAssignee: Martin Betak <mbetak>
Status: CLOSED CURRENTRELEASE QA Contact: Nisim Simsolo <nsimsolo>
Severity: low Docs Contact:
Priority: high    
Version: ---CC: acanan, bazulay, bugs, ebenahar, gklein, iheim, mavital, mbetak, mgoldboi, michal.skrivanek, nsimsolo, rbalakri, sbonazzo, s.kieske, srevivo, yanying906
Target Milestone: ovirt-4.0.0-alphaKeywords: FutureFeature, Reopened
Target Release: 4.0.0Flags: rule-engine: ovirt-4.0.0+
gklein: testing_plan_complete+
mgoldboi: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: ovirt 4.0.0 alpha1 Doc Type: Enhancement
Doc Text:
This release improves the user experience of guest OS installations. When using an installation CD and, after finishing with the OS installation, the CD is not used anymore and should be ejected, the suggested way is to use the Run Once dialog and attach the installation CD, then use "Start in paused mode" and/or "Enable boot menu" to select the boot media (CD) once. For this purpose the layout was changed so that these options are now right next to the Attach CD drop-down list.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-05 07:46:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 751854    

Description Sven Kieske 2014-01-16 08:03:56 UTC
Description of problem:

when you restart a vm from within that vm (e.g. via CLI "reboot" command)
a prior attached cd-rom via "run-once" function (e.g.) cloud-init
does not get removed

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


How reproducible:
always

Steps to Reproduce:
1. create a linux vm
2. start it with cloud-init data
3. reboot the vm from within

Actual results:

the cd rom is still attached, with the iso still available
leading to possible unwanted information leakage


Expected results:

vdsm detects the qemu reboot and detaches the vm payload
(restarting the qemu process? I'm not 100% sure how the exact workflow would
be) resulting in the vm being rebooted without the attached iso.


Additional info:

after all, the function is called "run once" so users might expect that
this information is gone after a reboot/shutdown within the vm!

Itamar requested that this would be filed as an RFE in BZ1038121

Comment 1 Michal Skrivanek 2014-01-17 12:07:18 UTC
this should work already for sysprep floppies (via volatileFloppy), perhaps should do the same for CDs.
Full Run Once reset is not really possible without engine involvement so I'd limit it to engine's actions (engine's initiated "full" Reboot based on http://gerrit.ovirt.org/#/c/15829/, not the one in 3.4)

Comment 2 Michal Skrivanek 2014-04-03 13:18:02 UTC
maybe we can consider only "resetting" the boot order…

Comment 3 Michal Skrivanek 2014-04-03 13:18:12 UTC
*** Bug 1072671 has been marked as a duplicate of this bug. ***

Comment 4 Michal Skrivanek 2014-05-23 12:20:18 UTC
we should add the "-no-reboot" to kvm and handle it by engine, then it's going to finally work for reboots triggered by  the guest as well….

Comment 5 Sven Kieske 2014-05-23 12:32:08 UTC
what if -no-reboot is set and I want to expose the reboot option of ovirt
via rest to customers?

I want the customer to be able to start with run-once via rest

_and_ I want him to be able to trigger the reboot via rest

with the same commands as of today.

Would the option "-no-reboot" affect this?

Reading the qemu documentation it seems it _will_ affect this
usecase, because it states: "shutdowns the vm instead of rebooting it".

So if this flag gets enabled and I issue a reboot command from outside
via rest, will the vm reboot or shutdown? because it still should reboot
when I call reboot from outside.

It just should not reboot with the cd rom attached.

I can't think of another way to handle this problem than altering
the libvirt xml of the vm on-the-fly (is this supported for cd roms?).

What do you think?

Comment 6 Michal Skrivanek 2014-05-27 08:54:11 UTC
let's start with a new VM "create" parameter to support -no-reboot

Comment 7 Shahar Havivi 2014-05-28 09:44:04 UTC
(In reply to Sven Kieske from comment #5)
The solution that we are suggesting is to shutdown on reboot - The Engine will get and exit code why the VM was shutdown - if it was for a reboot reason - the Engine will restart the VM without the run-once parameters.
As for the REST scenario that you mention the Engine will fall to that case as well since it will know that it wanted to reboot and not shutdown.

Comment 8 Michal Skrivanek 2014-06-10 08:46:50 UTC
we can't use the -no-reboot flag since it disconnects the console:-(

Comment 9 Michal Skrivanek 2014-08-04 12:56:43 UTC
(In reply to Michal Skrivanek from comment #8)
> we can't use the -no-reboot flag since it disconnects the console:-(
well, though this is the only way how to do that right now, so let's proceed despite that:)

Comment 10 Omer Frenkel 2014-09-04 06:49:17 UTC
*** Bug 1136819 has been marked as a duplicate of this bug. ***

Comment 11 Omer Frenkel 2014-11-05 07:37:28 UTC
*** Bug 1160460 has been marked as a duplicate of this bug. ***

Comment 12 Michal Skrivanek 2015-06-05 11:44:19 UTC
This bug did not make it in time for 3.6 release, moving into the next one

Comment 13 Sandro Bonazzola 2015-09-04 09:01:47 UTC
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

Comment 14 Sandro Bonazzola 2015-10-02 10:54:35 UTC
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
anymore.
Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still
an issue.

Comment 15 Yaniv Kaul 2015-11-26 15:55:52 UTC
(In reply to Shahar Havivi from comment #7)
> (In reply to Sven Kieske from comment #5)
> The solution that we are suggesting is to shutdown on reboot - The Engine
> will get and exit code why the VM was shutdown - if it was for a reboot
> reason - the Engine will restart the VM without the run-once parameters.
> As for the REST scenario that you mention the Engine will fall to that case
> as well since it will know that it wanted to reboot and not shutdown.

I remember this suggestion (for various reasons) in 2008 or so. I'm really in favor.

Comment 16 Michal Skrivanek 2016-03-24 10:16:59 UTC
we can do a slightly different change, but it should be what is actually wanted:

Run Once would enable boot menu by default to give people a chance to switch boot media, and that's it...
We may also suggest(make it a default behavior) that Run Once start in paused mode to make sure you don't miss the menu

Comment 17 Red Hat Bugzilla Rules Engine 2016-03-24 14:24:40 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 18 Mike McCune 2016-03-28 23:03:07 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 19 Michal Skrivanek 2016-03-29 10:37:59 UTC
what about the paused mode?

Comment 20 Martin Betak 2016-03-29 11:08:10 UTC
By default we don't want all run once VMs to be ran in paused mode (unless specified in vm configuration beforehand). But the checkbox has been moved just under the "show boot menu" checkbox so when user wants to achieve this behavior he will see it immediately.

Comment 21 Michal Skrivanek 2016-03-29 11:12:36 UTC
Moran, I propose to start losing these requests/bugs with this current solution. It should address the need just fine and any other solution is way too far away/complex.

Comment 22 Michal Skrivanek 2016-03-29 14:38:10 UTC
(In reply to Michal Skrivanek from comment #21)
*closing*, not losing;-)

Comment 23 Moran Goldboim 2016-04-03 11:51:49 UTC
(In reply to Michal Skrivanek from comment #21)
> Moran, I propose to start losing these requests/bugs with this current
> solution. It should address the need just fine and any other solution is way
> too far away/complex.

my only problem is with the duplicated function of the boot order, once from within the admin portal and the other from the guest console. would it introduce problems in automatic installation flow?

Comment 24 Michal Skrivanek 2016-04-05 06:43:50 UTC
it doesn't change a thing, but indeed it would be better to hide it a bit more. That's why we moved the boot menu checkbox above it

Comment 25 Nisim Simsolo 2016-06-13 12:48:26 UTC
Verified. Test case added to external trackers

Comment 26 Sandro Bonazzola 2016-07-05 07:46:20 UTC
oVirt 4.0.0 has been released, closing current release.