Created attachment 1771319 [details] engine log Description of problem: Can't change CD in a running vm, it fails with the following error: 2021-04-12 12:02:21,959+03 ERROR [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-46) [4973af44-2241-4065-b4e0-d74137190b4e] Command 'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand' failed: UUID string too large 2021-04-12 12:02:21,959+03 ERROR [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-46) [4973af44-2241-4065-b4e0-d74137190b4e] Exception: java.lang.IllegalArgumentException: UUID string too large at java.base/java.util.UUID.fromString(UUID.java:199) at org.ovirt.engine.core.compat//org.ovirt.engine.core.compat.Guid.<init>(Guid.java:67) at org.ovirt.engine.core.compat//org.ovirt.engine.core.compat.Guid.createGuidFromStringWithDefault(Guid.java:87) at org.ovirt.engine.core.compat//org.ovirt.engine.core.compat.Guid.createGuidFromString(Guid.java:76) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand.perform(ChangeDiskCommand.java:102) ... at org.jboss.xnio.12.Final-redhat-00001//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280) at java.base/java.lang.Thread.run(Thread.java:834) 2021-04-12 12:02:21,963+03 ERROR [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-46) [4973af44-2241-4065-b4e0-d74137190b4e] Transaction rolled-back for command 'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand'. 2021-04-12 12:02:21,972+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-46) [4973af44-2241-4065-b4e0-d74137190b4e] EVENT_ID: USER_FAILED_CHANGE_DISK_VM(102), Failed to change disk in VM testvm (Host: host_mixed_2, User: admin@internal-authz). Version-Release number of selected component (if applicable): ovirt-engine-4.4.6.3-0.8.el8ev.noarch How reproducible: 100% Steps to Reproduce: 1. Create a VM and run once with a certain cd(the test used en_windows_10_enterprise_x64_dvd_6851151.iso) 2. After VM is up, change CD(the test used en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso) Actual results: 1. Changing CD failed, errors in engine log are as above. Expected results: 1. Changing CD succeeds. Additional info:
seems related to the fix to bz 1589763
Vojtech, Please have a look?
(In reply to Eyal Shenitzky from comment #2) > Vojtech, > > Please have a look? already looking
Cloud you please provide exact procedure how to reproduce? I'm not able to reproduce. Maybe related to image names?
(In reply to Vojtech Juranek from comment #4) > Cloud you please provide exact procedure how to reproduce? I'm not able to > reproduce. Maybe related to image names? yes, it's definitely related to the image name. pick one with length(name)>36 (Qin used "en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso")
(In reply to Arik from comment #5) > (In reply to Vojtech Juranek from comment #4) > > Cloud you please provide exact procedure how to reproduce? I'm not able to > > reproduce. Maybe related to image names? > > yes, it's definitely related to the image name. doesn't looks so > pick one with length(name)>36 (Qin used > "en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso") tried to upload image with name "en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.raw" and CD change still works
You probably use a data domain, try an iso domain where we don't use the image id as the identifier
(In reply to Arik from comment #7) > You probably use a data domain, try an iso domain where we don't use the > image id as the identifier Yes, this is what came to my mind as well and this is the way how to reproduce it. I'll post a patch for it which shouldn't affect ISOs on block SD (AFAIK iso SD can be only on file SD), but please note ISO SD is deprecated and shouldn't be used. Trying to create ISO domain, I found out that ovirt-iso-uploader is broken and won't be fixed (see BZ #1804688), so this really doesn't look like something what we still support.
yeah, ISO domains can only be file storage. about the support of ISO domains - I'm afraid that it would still be a pretty common case to use ISO domains despite its deprecation. not only for flows that require ISO domains like IMS based migrations but also in upgraded environments which are probably the vast majority of deployments out there. so while it makes sense to deprecate it so we won't invest time on enhancing that, we must ensure that it's still tested and existing ISO domains still work
please make sure this is covered by OST
(In reply to Arik from comment #9) > yeah, ISO domains can only be file storage. > about the support of ISO domains - I'm afraid that it would still be a > pretty common case to use ISO domains despite its deprecation. not only for > flows that require ISO domains like IMS based migrations but also in > upgraded environments which are probably the vast majority of deployments > out there. so while it makes sense to deprecate it so we won't invest time > on enhancing that, we must ensure that it's still tested and existing ISO > domains still work Right. Vojtech, changing CD for ISO domain should work with the 'old way' (without PDIV) since it is a file-based domain, right?
(In reply to Eyal Shenitzky from comment #11) > (In reply to Arik from comment #9) > > yeah, ISO domains can only be file storage. > > about the support of ISO domains - I'm afraid that it would still be a > > pretty common case to use ISO domains despite its deprecation. not only for > > flows that require ISO domains like IMS based migrations but also in > > upgraded environments which are probably the vast majority of deployments > > out there. so while it makes sense to deprecate it so we won't invest time > > on enhancing that, we must ensure that it's still tested and existing ISO > > domains still work > > Right. > Vojtech, changing CD for ISO domain should work with the 'old way' (without > PDIV) since it is a file-based domain, right? yes, with patched linked to this bug CDs from ISO domains still work, using the old way for chnaging CD.
*** Bug 1950921 has been marked as a duplicate of this bug. ***
Verified with: ovirt-engine-4.4.6.5-447.gd80dda7.9.el8ev.noarch Steps: 1. Attach ISO domain 2. Create a VM, run once with a certain cd(en_windows_10_enterprise_x64_dvd_6851151.iso) 3. After VM is up, change CD(en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso) Results: 1. Change CD succeeded. dumpxml before changing CD: [root@caracal05 ~]# virsh -r dumpxml test_vm ... <disk type='file' device='cdrom'> <driver name='qemu' type='raw' error_policy='report'/> <source file='/rhev/data-center/mnt/nfs-server:_iso__domain/d31037e5-0d45-4306-975b-73eea845ae86/images/11111111-1111-1111-1111-111111111111/en_windows_10_enterprise_x64_dvd_6851151.iso' startupPolicy='optional' index='1'> <seclabel model='dac' relabel='no'/> </source> <backingStore/> <target dev='sdc' bus='sata'/> <readonly/> <boot order='1'/> <alias name='ua-e81b516c-d8e6-4eeb-ad07-4e992d1ded25'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> ... dumpxml after changing CD: [root@caracal05 ~]# virsh -r dumpxml test_vm ... <disk type='file' device='cdrom'> <driver name='qemu' type='raw' error_policy='report'/> <source file='/rhev/data-center/mnt/nfs-server:_iso__domain/d31037e5-0d45-4306-975b-73eea845ae86/images/11111111-1111-1111-1111-111111111111/en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso' index='2'/> <backingStore/> <target dev='sdc' bus='sata'/> <readonly/> <boot order='1'/> <alias name='ua-e81b516c-d8e6-4eeb-ad07-4e992d1ded25'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> ... engine.log shows CD en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso was inserted to VM: 2021-04-21 10:10:55,282+03 INFO [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] Running command: ChangeDiskCommand internal: false. Entities affected : ID: 39baddae-ac2d-4a3f-a893-ebe3ea008107 Type: VMAction group CHANGE_VM_CD with role type USER 2021-04-21 10:10:55,285+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.IsoPrefixVDSCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] START, IsoPrefixVDSCommand(HostName = host_mixed_2, VdsAndPoolIDVDSParametersBase:{hostId='078aa3b9-0766-4e02-a781-a85fa05091da', storagePoolId='46e4001b-2830-4bd8-a75e-f1fedbec8a83'}), log id: 5f98ffaf 2021-04-21 10:10:55,286+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.IsoPrefixVDSCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] FINISH, IsoPrefixVDSCommand, return: /rhev/data-center/mnt/nfs-server:_iso__domain/d31037e5-0d45-4306-975b-73eea845ae86/images/11111111-1111-1111-1111-111111111111, log id: 5f98ffaf 2021-04-21 10:10:55,286+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] START, ChangeDiskVDSCommand(HostName = host_mixed_2, ChangeDiskVDSCommandParameters:{hostId='078aa3b9-0766-4e02-a781-a85fa05091da', vmId='39baddae-ac2d-4a3f-a893-ebe3ea008107', iface='sata', index='2', diskPath='/rhev/data-center/mnt/nfs-server:_iso__domain/d31037e5-0d45-4306-975b-73eea845ae86/images/11111111-1111-1111-1111-111111111111/en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso', usingPdiv='false', driveSpec='null'}), log id: 41798349 2021-04-21 10:10:55,365+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] FINISH, ChangeDiskVDSCommand, return: Down, log id: 41798349 2021-04-21 10:10:55,366+03 INFO [org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] START, UpdateVmDynamicDataVDSCommand( UpdateVmDynamicDataVDSCommandParameters:{hostId='null', vmId='39baddae-ac2d-4a3f-a893-ebe3ea008107', vmDynamic='org.ovirt.engine.core.common.businessentities.VmDynamic@c5bba9d0'}), log id: 7f05081b 2021-04-21 10:10:55,367+03 INFO [org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] FINISH, UpdateVmDynamicDataVDSCommand, return: , log id: 7f05081b 2021-04-21 10:10:55,381+03 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-59) [393e66c4-c9c2-45bd-8179-01dc14513ac0] EVENT_ID: USER_CHANGE_DISK_VM(38), CD en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso was inserted to VM test_vm by admin@internal-authz.
This bugzilla is included in oVirt 4.4.6 release, published on May 4th 2021. Since the problem described in this bug report should be resolved in oVirt 4.4.6 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.