Bug 505900 - Host's general info tab requires more information
Host's general info tab requires more information
Status: CLOSED WONTFIX
Product: oVirt
Classification: Community
Component: ovirt-engine-core (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: lpeer
infra
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-14 11:50 EDT by Andrew Cathrow
Modified: 2014-09-07 18:52 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-11 01:41:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Cathrow 2009-06-14 11:50:36 EDT
The general sub-tab on the Host displays minimal information about the machine.
In environments with multiple hosts configured by DHCP it is difficult to uniquely identify machines.
This is especially a problem when you want to approve a host to enter the cluster since you are given little information other than the IP address and (dhcp) hostname.

Basic hardware details should be displayed on this tab to identify the machine.
The suggested fields are :

- Manufacturer
- Product Name
- Serial Number
- UUID
Comment 1 Miki Kenneth 2009-11-30 16:22:58 EST
what info do we have in DB? what can be added?
Comment 2 Omer Frenkel 2009-12-01 03:09:17 EST
Manufacture we don't have,
and the last 3 I don't know what they are,
this is what we do have (cut from vds view in the DB):
vds_group_id
vds_group_name
vds_group_description
selection_algorithm
vds_id
vds_name
ip
vds_unique_id
host_name
port
vds_strength
server_SSL_enabled
vds_type
subnet_mask
pm_type
pm_user
pm_password
pm_port
pm_options
pm_enabled
status
cpu_cores
cpu_model
cpu_speed_mh
if_total_speed
kvm_enabled
physical_mem_mb
pending_vcpus_count
mem_commited
vm_active
vm_count
vm_migrating
vms_cores_count
cpu_over_commit_time_stamp
hypervisor_type
net_config_dirty
high_utilization
low_utilization
max_vds_memory_over_commit
cpu_over_commit_duration_minutes
is_initialized
storage_pool_id
storage_pool_name
reserved_mem
guest_overhead
software_version
version_name
build_name
previous_status
cpu_idle
cpu_load
cpu_sys
cpu_user
usage_mem_percent
usage_cpu_percent
usage_network_percent
mem_available
mem_shared
cpu_flags
vds_group_cpu_name
cpu_sockets
vds_spm_id
spm_status
Comment 4 Yaniv Kaul 2010-01-04 04:07:27 EST
I guess we want the output of 'dmidecode -t 1' (example from an IBM we have
here):
Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: IBM
        Product Name: IBM System x3550 -[797861Y]-
        Version: Not Specified
        Serial Number: KDAPLLT
        UUID: AE0A6238-9CE0-3416-8C84-16A224E70650
        Wake-up Type: Power Switch
        SKU Number: Not Specified
        Family: Not Specified

and from an HP:
Handle 0x0100, DMI type 1, 27 bytes
System Information
        Manufacturer: HP
        Product Name: ProLiant DL360 G5
        Version: Not Specified
        Serial Number: GB88038NYC
        UUID: 34373030-3634-4742-3838-3033384E5943
        Wake-up Type: Power Switch
        SKU Number: 470064-623
        Family: ProLiant
Comment 5 Itamar Heim 2012-01-05 05:58:10 EST
placing on engine to collect this data.
would probably require a vdsm change to provide this and after backend has it, a change to the UI/API to expose it.
Comment 6 Itamar Heim 2012-12-11 01:41:22 EST
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

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