Bug 1581701 - The custom serial number policy does not work in 4.2
Summary: The custom serial number policy does not work in 4.2
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.2.4
: ---
Assignee: Arik
QA Contact: Polina
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-23 12:43 UTC by Jaroslav Spanko
Modified: 2021-09-09 14:17 UTC (History)
9 users (show)

Fixed In Version: ovirt-engine-4.2.4.4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-28 07:10:53 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:
lsvaty: testing_plan_complete-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-43503 0 None None None 2021-09-09 14:17:26 UTC
oVirt gerrit 91545 0 master MERGED core: honor vm serial number policy again 2021-02-04 10:28:50 UTC
oVirt gerrit 91652 0 ovirt-engine-4.2 MERGED core: honor vm serial number policy again 2021-02-04 10:28:50 UTC

Description Jaroslav Spanko 2018-05-23 12:43:25 UTC
Description of problem:
The custom serial number policy is ignored in 4.2

Version-Release number of selected component (if applicable):
RHV 4.2.3
vdsm-4.20.27.1-1.el7ev.x86_64
qemu-kvm-rhev-2.10.0-21.el7_5.2.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Edit VM custom serial number policy
2. Shutdown VM / start VM
3. The serial number reminds the same as before

Actual results:
This does not work in 4.2, 4.1 works as expected, it looks like problem during libvirt XML creation 

Expected results:
Working custom serial number policy

Additional info:

dumpxml 
  <sysinfo type='smbios'>
    <system>
      <entry name='manufacturer'>oVirt</entry>
      <entry name='product'>RHEV Hypervisor</entry>
      <entry name='version'>7.5-8.el7</entry>
      <entry name='serial'>4C4C4544-0031-5910-8033-B8C04F304432</entry>
      <entry name='uuid'>ebe2e258-53ca-4e60-9bf8-f7603360765d</entry>
    </system>
  </sysinfo>

VM
/usr/libexec/qemu-kvm -name guest=jspanko-7.4-v2v,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-58-jspanko-7.4-v2v/master-key.aes -machine pc-i440fx-rhel7.5.0,accel=kvm,usb=off,dump-guest-core=off -cpu Haswell-noTSX,vmx=on -m size=4194304k,slots=16,maxmem=16777216k -realtime mlock=off -smp 2,maxcpus=16,sockets=16,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -uuid ebe2e258-53ca-4e60-9bf8-f7603360765d -smbios type=1,manufacturer=oVirt,product=RHEV Hypervisor,version=7.5-8.el7,serial=4C4C4544-0031-5910-8033-B8C04F304432,uuid=ebe2e258-53ca-4e60-9bf8-f7603360765d

DB
     vm_name     | serial_number_policy |         custom_serial_number         
-----------------+----------------------+--------------------------------------
 jspanko-7.4-v2v |                    2 | 11111111-2222-3333-4444-555555555555

I will try to provide more info

Comment 4 Polina 2018-06-25 12:35:00 UTC
The bug is verified on rhv-release-4.2.4-6-001.noarch.

Change the custom serial number for running VM in System/Provide custom serial number policy affects as expected. 
the output in 'virsh -r dumpxml' - 
    <system>
      <entry name='manufacturer'>oVirt</entry>
      <entry name='product'>RHEV Hypervisor</entry>
      <entry name='version'>7.5-8.el7</entry>
      <entry name='serial'>1871e4b5-bfcb-4ec7-854f-555555555555</entry>
      <entry name='uuid'>1871e4b5-bfcb-4ec7-854f-5f829fd17cc9</entry>
    </system>

get vms rest response - 
        <serial_number>
            <policy>custom</policy>
            <value>1871e4b5-bfcb-4ec7-854f-555555555555</value>
        </serial_number>

Also tested with Rest API 

PUT https://{{host}}/ovirt-engine/api/vms/1871e4b5-bfcb-4ec7-854f-5f829fd17cc9
<vm>
	<serial_number>
		<policy>custom</policy>
		<value>1871e4b5-bfcb-4ec7-854f-555555555555</value>
	</serial_number>
</vm>

Comment 5 Franta Kust 2019-05-16 13:04:06 UTC
BZ<2>Jira Resync

Comment 6 Daniel Gur 2019-08-28 13:12:04 UTC
sync2jira

Comment 7 Daniel Gur 2019-08-28 13:16:17 UTC
sync2jira


Note You need to log in before you can comment on or make changes to this bug.