Created attachment 1713990 [details] logs Description of problem:VM with scsi hostdev (scsi_generic custom property) fails on start:Exit message: internal error: node-name 'libvirt-ua-a03481b3-d43c-4fa1-9566-640e092f384e-backend' too long for qemu Version-Release number of selected component (if applicable): ovirt-engine-4.4.3.1-0.7.el8ev.noarch How reproducible:100% Steps to Reproduce: 1. create VM on the base of last infra template latest-rhel-guest-image-8.2-infra 2. Attach scsi hostdev and configure scsi_generic custom property. (chosed device for the LUN that is not used by any SDs) 3. Run VM Actual results: VM vails on start . VM golden_env_mixed_virtio_1_0 is down with error. Exit message: internal error: node-name 'libvirt-ua-a03481b3-d43c-4fa1-9566-640e092f384e-backend' too long for qemu In the attached engine.log 2020-09-07 19:59:49,437+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-25) [] EVENT_ID: VM_DOWN_ERROR(119), VM golden_env_mixed_virtio_1_0 is down with error. Exit message: internal error: node-name 'libvirt-ua-a03481b3-d43c-4fa1-9566-640e092f384e-backend' too long for qemu. Expected results:vm starts Additional info: the same VM with the same attached scsi hostdev starts if custom property = scsi_hd or scsi_block
It seems that 'libvirt-ua-a03481b3-d43c-4fa1-9566-640e092f384e-backend' value is generated by libvirt and the fact that 'ua-a03481b3-d43c-4fa1-9566-640e092f384e' is a valid user-alias that later leads to an invalid value of node-name sounds like a problem on the libvirt side While we can change the user-alias assigned to hostdev on our side, I'd like to check it first with libvirt. Milan, can you please check where that comes from and whether it's possible to fix it at the libvirt-level?
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Created attachment 1714126 [details] logs second reproduce
I think it should be fixed in libvirt, so I filed a libvirt bug: Bug 1876984.
bz 1877675 is verified, do we need to upgrade the libvirt version we depend on?
(In reply to Arik from comment #5) > bz 1877675 is verified, do we need to upgrade the libvirt version we depend > on? I meant bz 1876467
Yes, if/once the given version is available in Advanced Virt. I'll post a patch.
verified on ovirt-engine-4.4.3.3-0.19.el8ev.noarch, qemu-kvm-core-5.1.0-9.module+el8.3.0+8182+ac9ced32.x86_64, vdsm-4.40.31-1.el8ev.x86_64, libvirt-6.6.0-6.module+el8.3.0+8125+aefcf088.x86_64
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.