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.

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 ;)

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?

(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.

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

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.

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.

Just closing this as suggested in Comment #8