Bug 1566456

Please also attach qemu.log

Created attachment 1425674 [details]
logs

added engine and vdsm libvirt logs. also edit window image . qemu.log is empty - VM failed with libvirt error 
2018-04-23 13:31:54.369+0000: 31390: error : virDomainUSBAddressAssign:2094 : internal error: No free USB ports (from libvirtd.log)

Michal, Sharon -

I'm wading through the code, but I'm not sure why High Performance would be different here

The VM isn't getting a controller model defined, although it looks like there's a default for ppc64.

<controller index="0" model="none" type="usb" />

os.other_ppc64.devices.usb.controller.value = nec-xhci

(In reply to Ryan Barry from comment #4)
> Michal, Sharon -
> 
> I'm wading through the code, but I'm not sure why High Performance would be
> different here
> 
> The VM isn't getting a controller model defined, although it looks like
> there's a default for ppc64.
> 
> <controller index="0" model="none" type="usb" />
> 
> os.other_ppc64.devices.usb.controller.value = nec-xhci

High Performance VMs are different since only for them the USB controller is really disabled. That's why you see that no usb controller is created.

I see that in this case the VM runs with VNC console so need to check why USB is required here.

Usually usb is required in case of VNC for the tablet input device but we handled that already in the code and it doesn't seem like the case here. 
So need to check what is the exact problem.

do you have the qemu log for this? It may not reproduce anymore too....

Hi, from the same run the qemu log was empty (please see the comment 3).
I'll reproduce the scenario as soon as I have ppc environment built.

Hi, I've reproduced the automation case in the ppc9 environment recently built (rhv-release-4.2.6-3-001.noarch). The VM start process fails immediately and the qemu log is not created. 

the bug was found while automation run. here are the manual way to reproduce:
1. System tab 
   Optimized for High Performance
   Total Virtual CPUs = 2

2. In Host tab 
   pin to host 1
   Don't allow migration
   Numa CPU Count = 2

3. Resource Allocation tab
   0#0_1#64

Close the Edit window , open again the 'Numa Pinning' in Host tab
pin vNuma to the nodes (Socket0, Socket1)


this matches to the automation test configuration:
Update existed vm golden_env_mixed_virtio_1_0 with {'placement_affinity': 'pinned', 'cpu_cores': 2, 'io_threads': 1, 'vcpu_pinning': [{'0': '0'}, {'1': '64'}], 'placement_hosts': ['host_mixed_1'], 'type': 'high_performance'}
Add NUMA node to VM with {'vm_name': 'golden_env_mixed_virtio_1_0', 'index': 0, 'pin_list': [0], 'host_name': 'host_mixed_1', 'memory': 512, 'cores': [0]}
Add NUMA node to VM with {'vm_name': 'golden_env_mixed_virtio_1_0', 'index': 1, 'pin_list': [8], 'host_name': 'host_mixed_1', 'memory': 512, 'cores': [1]}

(In reply to Polina from comment #9)
> Hi, I've reproduced the automation case in the ppc9 environment recently
> built (rhv-release-4.2.6-3-001.noarch). The VM start process fails
> immediately and the qemu log is not created. 
> 
Hi,

I verified that bug using a ppc host in my env. 
Polina's reproducing description mentioned in comment #9 didn't reproduce the problem and the VM started without any problem.

The bug was reproduced only after setting this HP VM to be non-headless (i.e. run the VM with VGA video device and with VNC graphics device).

Digging into it more deeper it seams that the VNC graphics device requires USB support although no mouse or tablet is defined (running with VGA without VNC didn't cause the error).

I searched in libvirt doc and didn't find something interesting.
Any ideas?

Do we have documentated support for HP PPC VMs with VNC graphics? I'd lean towards removing this combination from the UI and confirming your findings with platform

Probably worth to mention that this bug was found on IBM PPC and not HP PPC.

Sorry, Raz. I'm using HP to refer to high performance here, not the vendor

(In reply to Raz Tamir from comment #12)
> Probably worth to mention that this bug was found on IBM PPC and not HP PPC.

Sorry for the confusion in my description, but when I write "HP VM" in comment #10, I mean "High Performance VM type" and not regarding the cpu arch (it is a shortcut that we frequently us, but in this context it is confusing so sorry).

(In reply to Ryan Barry from comment #11)
> Do we have documentated support for HP PPC VMs with VNC graphics? I'd lean
> towards removing this combination from the UI and confirming your findings
> with platform
But in that case you won't be able to run a High Performance VM with a graphic console. The default for High Performance is headless mode, but we do want to enable graphic console if user prefers or even just in "Run Once" for installing operations.

Maybe the problem is that since in engine we removed input devices in case of High Performance vms and ppc, then for VNC - libvirt added a mouse or a tablet with bus="usb" as a default? Need to investigate that.

Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Closing old bug. Please reopen if still relevant/you want to work on it.