Created attachment 1872176 [details] engine log dump xmls Description of problem: Wrong pinning in the dedicated virsh dumpxml after migration in case of initial overlapping of cpu pinning all xml dumps before and after migration are attached Version-Release number of selected component (if applicable): ovirt-engine-4.5.0.2-0.7.el8ev.noarch How reproducible:100% Steps to Reproduce: 1. I run dedicated VM1 with 40 CPUs(1:20:2) on host1 (1:24:2). The manual VM2 with 2CPUS(2:1:1) is running on host2. For the dedicated VM we have a pinning 0#0_1#24_2#2_3#26_4#3_5#27_6#4_7#28_8#5_9#29_10#6_11#30_12#7_13#31_14#8_15#32_16#9_17#33_18#10_19#34_20#11_21#35_22#12_23#36_24#13_25#37_26#14_27#38_28#15_29#39_30#16_31#40_32#17_33#41_34#18_35#42_36#19_37#43_38#20_39#44 For the manual VM2 0#0_1#24 , so that there is an overlapping of two pCPUs and it must be changed while migration. 2. Migrate the dedicated VM1 to host2. It is migrated successfully . The cpu pinning changed . Actual results: in Get VMs I see <vcpu_pin> <cpu_set>2</cpu_set> <vcpu>0</vcpu> </vcpu_pin> <vcpu_pin> <cpu_set>26</cpu_set> <vcpu>1</vcpu> </vcpu_pin> ...... In VM -> Host Devices->'View CPU pinning' I see the expected change also 0#2_1#26_2#3_3#27_4#4_5#28_6#5_7#29_8#6_9#30_10#7_11#31_12#8_13#32_14#9_15#33_16#10_17#34_18#11_19#35_20#12_21#36_22#13_23#37_24#14_25#38_26#15_27#39_28#16_29#40_30#17_31#41_32#18_33#42_34#19_35#43_36#20_37#44_38#21_39#45 In virsh dumpxml though I see a different and seems like wrong pinning (the same to engine domxml): <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='4'/> <vcpupin vcpu='3' cpuset='5'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='7'/> <vcpupin vcpu='6' cpuset='8'/> ...... Expected results: Expected in virshdump the same pinning as in GET VMs Additional info: After investigation with Liran I add here the migration call from the attached engine log - 2022-04-13 15:37:52,052+03 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (default task-15) [666a02ac-8acb-4767-bb17-8159042034b4] START, MigrateVDSCommand( MigrateVDSCommandParameters:{hostId='73f6a190-312b-4229-a291-6f26bbb6db0c', vmId='8043 de20-f8e4-40c0-aa87-8e4b30604393', srcHost='ocelot05.qa.lab.tlv.redhat.com', dstVdsId='b5e11fa2-7a4d-4a9c-a82b-d7ff7947efa5', dstHost='ocelot06.qa.lab.tlv.redhat.com:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoCo nverge='false', migrateCompressed='false', migrateEncrypted='false', consoleAddress='null', maxBandwidth='62', parallel='null', enableGuestEvents='false', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='null', dstQemu='10.35.30 .6', cpusets='[2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45]', numaNodesets='null'}), log id: 489ac5a4 2022-04-13 15:37:52,054+03 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (default task-15) [666a02ac-8acb-4767-bb17-8159042034b4] START, MigrateBrokerVDSCommand(HostName = host_mixed_1, MigrateVDSCommandParameters:{hostId='73f 6a190-312b-4229-a291-6f26bbb6db0c', vmId='8043de20-f8e4-40c0-aa87-8e4b30604393', srcHost='ocelot05.qa.lab.tlv.redhat.com', dstVdsId='b5e11fa2-7a4d-4a9c-a82b-d7ff7947efa5', dstHost='ocelot06.qa.lab.tlv.redhat.com:54321', migrationMethod='ONLINE', tunnelMi gration='false', migrationDowntime='0', autoConverge='false', migrateCompressed='false', migrateEncrypted='false', consoleAddress='null', maxBandwidth='62', parallel='null', enableGuestEvents='false', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='null', dstQemu='10.35.30.6', cpusets='[2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45]', numaNodesets='null'}), log id: 62a573e0
Is it only when there are overlapping CPU that are being used on the destination host? I think it will be regardless VM2 sitting there. The problem is that the cpusets is incremental number (ordered) and should be set based on the physical hardware.
oh, yes Liran , you are right . It happens also without VM2. Of course I tested the scenario with only one VM before , but I think only GET VMs was checked and not virsh.
verified on ovirt-engine-4.5.0.5-0.7.el8ev.noarch tested scenario described in https://bugzilla.redhat.com/show_bug.cgi?id=2075037#c0 . the pinning of the dedicated VM is changed after the migration correctly. virsh dump and get VMs output are correct
This bugzilla is included in oVirt 4.5.0 release, published on April 20th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.0 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.