Bug 1683965

isn't it enough to use serial console for troubleshooting?

Sharon, looking at the code it looks wrong. Why does VmInfoBuildUtils::isTabletEnabled() checking vm.getGraphicsInfos().size() == 1 ? We now default to SPICE+VNC and so you do NOT add tablet in that case and I can confirm that in that case the VNC is unusable. This function should easily check for ostinfo USB controller instead, and that would solve this bug too

(In reply to Michal Skrivanek from comment #3)
> Sharon, looking at the code it looks wrong. Why does
> VmInfoBuildUtils::isTabletEnabled() checking vm.getGraphicsInfos().size() ==
> 1 ? We now default to SPICE+VNC and so you do NOT add tablet in that case
> and I can confirm that in that case the VNC is unusable. This function
> should easily check for ostinfo USB controller instead, and that would solve
> this bug too

The reason for checking VNC existence only (without SPICE) in VmInfoBuildUtils::isTabletEnabled() is since this was the original code before handling high performance and adding domain xml builder support -  Please see [1].
I only verified that it's not HP vm in that code and didn't touch the graphics checking- see [2].
In 4.1 the tablet device was added only for VNC (without SPICE). Isn't that the case?


[1] https://github.com/oVirt/ovirt-engine/blob/f6fe42e82bfb06297811989bbfb712174f5daa29/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/builder/vminfo/VmInfoBuilderImpl.java#L687

[2] https://gerrit.ovirt.org/#/c/83615/


Once you added a tablet, it shouldn't use USB. All USB devices logic is done today at VmDeviceUtils::updateUsbSlots(). So we can leave it there and set osinfo to "none" and just check in VmInfoBuildUtils::isTabletEnabled() if model is set to "none" and then treats it the same as HP vms....

Verified on:
ovirt-engine-4.3.5.3-0.1.el7.noarch

Steps:
1. Create a new OS profile:
- Create a new file in /etc/ovirt-engine/osinfo.conf.d called for example: 01-new-properties.
- In the file enter the new OS details:
os.new_os_name.id.value = <ID_NUMBER>
os.new_os_name.name.value = <NAME>
os.new_os_name.derivedFrom.value = other
os.new_os_name.devices.usb.controller.value = none

Where ID_NUMBER should be unique to the defults in 00-defaults.properties, NAME should be the new profile name.

2. Restart the engine:
$ service ovirt-engine restart

3. Create a new VM, set the OS to the <NAME>.
4. Set console to VNC.
5. Check for tablet/usb devices (virsh -r dumpxml <vm>)
6. Run the VM and open console.

Results:
The VM was created successfully with the new profile and VNC.
In step 5, only one USB device is shown: <controller type='usb' index='0' model='none'>
model='none' is disabled USB.
tablet doesn't exist.
Running the VM succeed, VNC and NoVNC console works.

> In step 5, only one USB device is shown: <controller type='usb' index='0' model='none'>

Please note that this RFE was about creating a VM without *any* USB devices, this sounds like the USB controller still exists? Thanks.

(In reply to Marko Myllynen from comment #10)
> > In step 5, only one USB device is shown: <controller type='usb' index='0' model='none'>
> 
> Please note that this RFE was about creating a VM without *any* USB devices,
> this sounds like the USB controller still exists? Thanks.

In https://libvirt.org/formatdomain.html#elementsControllers , under usb:

"Additionally, since 0.10.0, if the USB bus needs to be explicitly disabled for the guest, model='none' may be used."

So it seems to be the right behavior, Libvirt has similar thing when handling video devices - if we don't want a video device, we need to add a device with type 'none', otherwise libvirt inserts a default device. 

Bottom line, we need it for video device, but we set it to be explicitly disabled.

If i'm mistaken, Tomasz can maybe provide more information.

Right, thanks for pointing this out, so if the guest kernel does not see any USB devices then all should be good.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2431