Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 918138 - PRD35 - [RFE] Allow guest serial number to be configurable
Summary: PRD35 - [RFE] Allow guest serial number to be configurable
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.2.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: 3.5.0
Assignee: Martin Betak
QA Contact: Pavel Novotny
URL:
Whiteboard: virt
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2013-03-05 15:05 UTC by Tomas Dosek
Modified: 2019-04-16 14:01 UTC (History)
31 users (show)

Fixed In Version: ovirt-3.5.0-alpha1
Doc Type: Enhancement
Doc Text:
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 ______.
Clone Of:
Environment:
Last Closed: 2015-02-11 17:52:17 UTC
oVirt Team: ---
Target Upstream Version:
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 24274 None None None Never
oVirt gerrit 25099 None None None Never
oVirt gerrit 25100 None None None Never
oVirt gerrit 25101 None None None Never

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 <mbetak@redhat.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


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