|Summary:||PRD35 - [RFE] Allow guest serial number to be configurable|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||Tomas Dosek <tdosek>|
|Component:||RFEs||Assignee:||Martin Betak <mbetak>|
|Status:||CLOSED ERRATA||QA Contact:||Pavel Novotny <pnovotny>|
|Version:||3.2.0||CC:||aberezin, bsettle, cshao, danken, fdeutsch, gklein, gouyang, hadong, iheim, jbelka, jboggs, juan.hernandez, juwu, leiwang, lpeer, mavital, mchappel, michal.skrivanek, ngupta, ovirt-maint, pmukhedk, pnovotny, rbalakri, Rhev-m-bugs, rnelson, sherold, tdosek, yaniwang, ycui, yeylon, ylavi|
|Fixed In Version:||ovirt-3.5.0-alpha1||Doc Type:||Enhancement|
With this enhancement, it is now possible to configure serial numbers for virtual machines on three different levels: engine-config level, cluster level, and virtual machine level. At each level, three modes of serial numbers are available: use host UUID (legacy), use VM UUID, and provide custom serial number ______.
|Last Closed:||2015-02-11 17:52:17 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1142923, 1156165|
Comment 1 Mike Burns 2013-03-06 13:18:19 UTC
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.
Comment 2 Michal Skrivanek 2013-05-02 14:17:13 UTC
if it's in libvirt's xml you should be able to use a before_vm_start hook for that pls confirm
Comment 3 Tomas Dosek 2013-05-02 14:36:37 UTC
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.
Comment 4 Michal Skrivanek 2013-05-02 14:40:53 UTC
then changing to RFE;-) I don't think this little modification would violate support so I'm considering this minor
Comment 7 Andrew Cathrow 2013-07-11 21:52:01 UTC
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?
Comment 8 Michal Skrivanek 2013-09-12 10:00:24 UTC
the effort differs significantly global option is trivial, per VM property with options would take more
Comment 9 Andrew Cathrow 2013-09-12 13:42:28 UTC
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)
Comment 15 Martin Betak 2014-02-17 15:15:25 UTC
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.
Comment 16 Juan Hernández 2014-02-19 14:34:18 UTC
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.
Comment 18 Juan Hernández 2014-02-19 15:15:22 UTC
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.
Comment 19 Dan Kenigsberg 2014-02-19 15:29:21 UTC
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.
Comment 21 Dan Kenigsberg 2014-02-25 06:52:57 UTC
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 <email@example.com> Date: Mon Feb 10 15:29:46 2014 +0100 vdsm: Enable config of VM serial number
Comment 22 Dan Kenigsberg 2014-02-25 07:13:53 UTC
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".
Comment 23 Jiri Belka 2014-07-01 13:54:34 UTC
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)
Comment 24 Pavel Novotny 2014-07-25 10:11:59 UTC
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
Comment 25 Pavel Novotny 2014-07-28 14:23:24 UTC
Moving back to ON_QA. Will be re-verified in the next downstream RHEVM build.
Comment 27 Pavel Novotny 2014-09-12 16:29:37 UTC
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
Comment 28 Yaniv Lavi 2015-01-19 15:35:50 UTC
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.
Comment 30 errata-xmlrpc 2015-02-11 17:52:17 UTC
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