Bug 970083 - Drop 'Direct Kernel Boot' for non-Linux based VMs
Drop 'Direct Kernel Boot' for non-Linux based VMs
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-manager (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity low
: rc
: ---
Assigned To: Pavel Hrdina
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-03 08:37 EDT by Jiri Belka
Modified: 2016-04-26 10:04 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-04 19:59:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiri Belka 2013-06-03 08:37:52 EDT
Description of problem:

We dropped 'Direct Kernel Boot' options for non-Linux based VMs in RHEVM - BZ909127. Please drop it in virt-manager too as it does not make sense for non-Linux based guests.

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

How reproducible:
100%

Steps to Reproduce:
1. create non-Linux based guest
2. check boot options for 'Direct Kernel Boot'
3.

Actual results:
'Direct Kernel Boot' options are enabled for non-Linux based guests

Expected results:
enable this option only for "supported" OS types (Linux-based ones)

Additional info:
qemu-kvm --help shows
Linux/Multiboot boot specific:
-kernel bzImage use 'bzImage' as kernel image
-append cmdline use 'cmdline' as kernel command line
-initrd file    use 'file' as initial ram disk
Comment 2 Martin Kletzander 2013-06-03 12:08:19 EDT
I see there are various possibilities how to make use of this option with windows guests.  The same use cases apply as those where you want to boot a different system to for example rescue the original system etc.  We offer all the options user may try to use.  Plus the only way we know the machine doesn't run Linux is when user selects a OS type: Windows.

One other use case to account against this change: Multiboot scenarios with kernel being merely a "boot-loader" deciding what will be ran in the machine.  I'm not saying this is used often or at all, but we would restrict the option here.  Also the options for Direct kernel boot are not taking any space that (when removed) would somehow help orienting in the GUI.

Feel free to correct me in case I missed something, but TBH, the fact that "RHEV-M drops this options for Windows guests" doesn't seem like the right reason to me.

Let me know whether I missed something, otherwise I'll have to close this as NOTABUG.  Thanks.
Comment 3 Jiri Belka 2013-06-04 03:07:32 EDT
I've seen this point too. So generally two options, either you keep it as it is or there should be a knob for changing OS type and according to the type this option should or should not be visible. It's up to you ;)
Comment 4 Martin Kletzander 2013-06-04 07:13:25 EDT
That would mean keeping another information about VMs on top of all the info we get from libvirt.

virt-manager has no idea about what system is running in the guest.  We only ask that info on creation to know what hardware we should create the guest with (due to compatibility).  Keeping this info would require new temporary storage for each VM.

Another problem would be how to deal with VMs which were not created with virt-manager; how do we know what system runs inside?  Do we bother asking the user?  What if a machine gets migrated while virt-manager is running, is popup window to intrusive?

I guess my point is, that after implementing all of this functionality, we would just create a permanent data storage just to know whether to hide one line from the GUI, which doesn't seem very useful nor intuitive to me.  Does that 'Direct kernel boot' option (which is even collapsed by default) bother you really *that* much?
Comment 5 Dave Allan 2013-06-04 09:57:54 EDT
(In reply to Martin Kletzander from comment #4)
> virt-manager has no idea about what system is running in the guest.  We only
> ask that info on creation to know what hardware we should create the guest
> with (due to compatibility).  Keeping this info would require new temporary
> storage for each VM.

It doesn't seem worth it for this BZ, but in general I think we should plan for virt-manager tracking what OS is running in the guest since libvirt explicitly does not.  Yes, it creates a bunch of complexity, but IMO it's worth it since so much depends on the guest OS.
Comment 6 hyao@redhat.com 2013-06-19 04:54:34 EDT
I've reproduced the bug with the following packages: 
libvirt-1.0.6-1.el7.x86_64
virt-manager-0.10.0-0.5.gitde1695b2.el7.noarch
Comment 7 hyao@redhat.com 2013-07-29 05:05:58 EDT
Reproduced the bug with the following packages and steps: 
# rpm -qa libvirt virt-manager
libvirt-1.1.0-2.el7.x86_64
virt-manager-0.10.0-1.el7.noarch

Steps: 
1. Create a non-Linux vm 
2. Check the vm details by Show virtual hardware detail->Boot Options

Actual result:
Direct kernel boot is there.
Comment 8 Jiri Belka 2015-05-27 06:00:26 EDT
FYI I was wrong, see:

https://bugzilla.redhat.com/show_bug.cgi?id=1221637

Either close as won't fix or just change name as written in #1221637. Thx.
Comment 10 Cole Robinson 2015-11-04 19:59:19 EST
Just closing this as suggested in Comment #8

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