This is controlled by RHEV-M, not RHEV-H. RHEV-H simply takes the libvirt XML and runs it. It doesn't control any ID's. If they need to be coordinated across hosts, then it has to be done through management and not through the hypervisor host.
if it's in libvirt's xml you should be able to use a before_vm_start hook for that pls confirm
The hook exists and is being used for this purpose. However by using the hook customer gets outside of the terms of support for RHEV-M product. This is the reason for filing the bug.
then changing to RFE;-) I don't think this little modification would violate support so I'm considering this minor
Changing description to add an option to not change serial number. This would be an advanced option in VM configuration. Michal - let's look at this for 3.4 - perhaps as a custom property?
the effort differs significantly global option is trivial, per VM property with options would take more
Restating requirements: Provide an option to specify the serial number exposed to the guest. Today we use HostID+UUID This means that we do not use a consistent serial number which has the potential to confuse some systems that expect the serial number to be static. Add a new advanced config option for a VM. Serial Number: 1) *default* HostID + UUID 2) UUID 3) Custom ___________ (free text)
During the REST-API design for this feature there were some questions raised about whether there is use case for the "Use Host UUID" mode for serial number. Do we need to maintain the backwards compatibility with current behavior in this regard and should this mode be the default? From the above comments I get the impression that almost all use cases will be served by "Use VM UUID" and "Use custom: _________ ". Thanks.
Andrew, we need your comments regarding comment 15. In my opinion the option to use the host id (as we do today) is useless. We should by default use an unique id (the same that the VM) and allow the user to override it only at the VM level, not at the cluster level. In the RESTAPI this should be as simple as adding a new <serial_number> element to the VM description.
What I'm suggesting is to use, by default, the id of the VM as the serial number. The user will still be able to override that and provide any serial number he wants. From the RESTAPI point of view, a request like this: POST /api/vms HTTP/1.1 <vm ...> <!-- No serial number provided. --> </vm> Should create a VM with a serial number equal to the VM identifier, which is unique. A request like this: POST /api/vms HTTP/1.1 <vm ...> <serial_number>whatever_the_user_whants</serial_number> </vm> Should create a VM with the serial number that the user selects. Of course the user will be allowed to create many VMs with the same serial number.
The use case of passing the host id as serial number is laid out in bug 501440. It did not convince me back then, but I complied anyway. This must be kept now, at least as a non-default option, for backward compatibility. You do not want to risk a guest seeing a different bios due to an Engine upgrade.
Vdsm-side patch is merged upstream and would be part of ovirt-3.5. I believe the Engine-side patch is still pending. commit 85e83637fa47d96f7728040810eb99704d07fcf0 Author: Martin Betak <mbetak> Date: Mon Feb 10 15:29:46 2014 +0100 vdsm: Enable config of VM serial number
Until this RFE is implemented, users may install http://resources.ovirt.org/releases/3.3/rpm/EL/6/noarch/vdsm-hook-smbios-4.13.3-3.el6.noarch.rpm and set their VM "serial" as an explicit custom property. With small alteration, this hook may copy the VM's uuid into its "serial".
ok, ovirt-engine-webadmin-portal-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch tested from my fav OS (sysctl hw.serialno: got 3 valid values)
Re-verified in upstream ovirt-engine-3.5.0-0.0.master.20140722232058.git8e1babc.el6.noarch (beta2). Verified that started guest has set correct serial number, which has been defined on one or more of the following locations: - cluster: Host ID, Vm ID, Custom - VM: Host ID, Vm ID, Custom - template: Host ID, Vm ID, Custom - engine global defaults: DefaultSerialNumberPolicy=HOST_ID|VM_ID|CUSTOM & DefaultCustomSerialNumber=<UUID> If different serial number policies are defined at more places at once, the priorities are following (from lowest to highest): 1) engine global default 2) cluster level 3) template level 4) VM level
Moving back to ON_QA. Will be re-verified in the next downstream RHEVM build.
Re-verified in downstream rhevm-3.5.0-0.11.beta.el6ev.noarch (vt3). Verified that started guest has set correct serial number, which has been defined on one or more of the following locations: - cluster: Host ID, Vm ID, Custom - VM: Host ID, Vm ID, Custom - template: Host ID, Vm ID, Custom - engine global defaults: DefaultSerialNumberPolicy=HOST_ID|VM_ID|CUSTOM & DefaultCustomSerialNumber=<UUID> If different serial number policies are defined at more places at once, the priorities are following (from lowest to highest): 1) engine global default 2) cluster level 3) template level 4) VM level
Original request was: 1. What is the nature and description of the request? The customer application depends on the serial number in dmidecode to establish the system uniqueness. But this value changes depending on which RHEV-Host the vm starts on . 2. Why does the customer need this? (List the business requirements here) Customer application depends on this value to confirm the systems unique identity. 3. How would the customer like to achieve this? (List the functional requirements here) Application reads serial number from dmidecode on RHEV guest & finds it same, irrespective of which RHEV-Host it boots on.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html