Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 972584 - VM's name (db name) available from within the guest
VM's name (db name) available from within the guest
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
All All
unspecified Severity medium
: ---
: ---
Assigned To: Andrew Cathrow
: Improvement
Depends On:
  Show dependency treegraph
Reported: 2013-06-10 03:28 EDT by Daniele
Modified: 2015-09-22 09 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-11 05:39:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniele 2013-06-10 03:28:05 EDT
1. Proposed title of this feature request
VM's name (db name) available from within the guest

2. Who is the customer behind the request?
Account: ASML Netherlands B.V. (988717)
TAM customer: yes
SRM customer: no
Strategic: yes

3. What is the nature and description of the request?

4. Why does the customer need this? (List the business requirements here)
All their virtual machines have the same hostname due to the application they are running. Developers create several vm's and want to incorporate the name of the vm (not the hostname) into their prompt or into the title of their xterm to make it clear on which vm they are working. At the moment this is not known within the vm.

5. How would the customer like to achieve this? (List the functional requirements here)
To have the name of the vm available within the vm, either in a file or as the output of a command. 
They suggested the qemu process on the hypervisor to write (part of) the dom.xml of the VM to the VM and that the ovirt-guest-agent saves this data somewhere in the VM.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Check for the vm's name

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

9. Is the sales team involved in this request and do they have any additional input?

10. List any affected packages or components.

11. Would the customer be able to assist in testing this functionality if implemented?
Comment 1 Itamar Heim 2013-06-10 07:10:30 EDT
have they looked at using the payload for this?
(next option is probably cloud-init in 3.3)
Comment 2 Daniele 2013-06-11 07:54:00 EDT
Hello Itamar,

We're not sure what you are referring to, when talking about payload.
What is it? How would it help? Any document you can share?
Comment 3 Itamar Heim 2013-06-11 08:38:06 EDT
payload can be defined for a VM via the REST API to pass any information to the guest via a block device or iso attached to the guest.

please look for 'payload' in:

cloud-init (3.3) will allow to do this via run-once, and maybe via editing the cloud-init template (tbd)
Comment 4 Itamar Heim 2013-06-20 02:12:02 EDT
greg - i assume hostname in the config disk already passes this per the example in http://www.ovirt.org/Features/Cloud-Init_Integration

Daniele - please check if the cloud-init via run-once approach satisfies this request from the customer.
Comment 5 Greg Padgett 2013-06-20 02:52:03 EDT
(In reply to Itamar Heim from comment #4)
> greg - i assume hostname in the config disk already passes this per the
> example in http://www.ovirt.org/Features/Cloud-Init_Integration

VM name is the default hostname when enabling cloud-init from the web-based UIs--either webadmin or user portal.

For REST API, I supposeit could be scripted in 2 ways: either send the vm name as the hostname, or add a file attachment containing the vm name (similar to the payload that you mentioned in comment 1).

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