EXAMPLES OF COLLECTED DETAILS¶

The following examples are YAML representations of the details that are collected from a QEMU/KVM Libvirt host and a VMWare vCenter:

[libvirt1]
kvmhost1.example.com:


  capabilities:


    cpu_topology:


      arch: x86_64


      cores: 8


      sockets: 2


      threads: 1


    ram_mb: 128781


    type: QEMU


  id: af78bfa8-67df-4d84-8d32-e40eb2404ac1


  name: sle15-dev


  vms:


    some-workload-vm-1:


      uuid: c44bae94-bab0-44f5-8603-0d770344facc


      vmState: running


    some-workload-vm-2:


      uuid: f5319c28-377f-46fe-acee-5509a356f652


      vmState: running


    some-workload-vm-3:


      uuid: 51b62ad3-effd-45db-b508-1ac47a528b93


      vmState: running


    some-workload-vm-4:


      uuid: cf46f104-5806-4ddd-9e99-32d167d063a3


      vmState: running
[vcenter1]
esx1.dc1-vcenter.example.com:


  capabilities:


    cpu_topology:


      arch: x86_64


      cores: 12


      sockets: 2


      threads: 24


    ram_mb: 253917


    type: vmware


  id: '''vim.HostSystem:host-15'''


  name: esx1.dc1-vcenter.example.com


  vms:


    some-workload-vm-1:


      uuid: 422270db-f382-4955-8cbd-75736a64089b


      vmState: running


      vmware_uuid: 422270db-f382-4955-8cbd-75736a64089b


    another-workload-vm-2:


      uuid: 4222dec1-6226-4f44-95e4-05156ea0f4b5


      vmState: running


      vmware_uuid: 4222dec1-6226-4f44-95e4-05156ea0f4b5
esx2.dc1-vcenter.example.com:


  capabilities:


    cpu_topology:


      arch: x86_64


      cores: 12


      sockets: 2


      threads: 24


    ram_mb: 262109


    type: vmware


  id: '''vim.HostSystem:host-27'''


  name: esx2.dc1-vcenter.example.com


  vms:


    another-workload-vm-1:


      uuid: 42225602-4139-44fb-b111-e5b8df028b1c


      vmState: running


      vmware_uuid: 42225602-4139-44fb-b111-e5b8df028b1c


    linux-workload-vm-3:


      uuid: 5dec2242-969f-1dee-8137-209da409ec2b


      vmState: running


      vmware_uuid: 4222ec5d-9f96-ee1d-8137-209da409ec2b


    linux-workload-vm-1:


      uuid: 564d2049-beb3-8f38-bfea-488d2a4186cd


      vmState: running


      vmware_uuid: 564d2049-beb3-8f38-bfea-488d2a4186cd


    linux-workload-vm-2:


      uuid: 7e0f2242-f1c3-dd4a-b902-18f602165074


      vmState: running


      vmware_uuid: 42220f7e-c3f1-4add-b902-18f602165074
    

HYPERVISOR ACCESS CREDENTIALS¶

Any hypervisor access credentials that are provided for use with the scc-hypervisor-collector(1) should have minimal privileges sufficent to allow retrieving the required details about the hypervisor nodes and then VMs running on them.

CONFIGURATION SETTINGS & LOG FILE PERMISSIONS¶

As the scc-hypervisor-collector(5) configuration settings will contain sensitive information such as passwords, the command requires that all specified configuration files and directories must be owned by the non-root user that is running the command, with restrictive permissions allowing only that user to access those files.

Similarly, while every effort has been taken to ensure that no sensitive data is being written to the log files, to limit potential exposure of such information the log files must also be owned by, and only accessible by, the user that is running the scc-hypervisor-collector(5) command.

TLS/SSL CERTIFICATES¶

The virtual-host-gatherer(1) framework only supports certs that are registered with the system certificate stores. See update-ca-certificates(8) for details.

SSH KEYS¶

For any Libvirt hypervisors that are specified with a qemu+ssh type URI, appropriate SSH keys that support passwordless SSH access to the target hypervisor node, must be available in the ~/.ssh/ directory.

See ssh-keygen(1) for more details on how to generate appropriate SSH keys if needed, and ssh(1) for the appropriate permissions for the ~/.ssh/ directory and any keys stored there.

SEPARATE COLLECTION AND UPLOAD RUNS¶

Leveraging the -o/--output and -i/--input options, it will be possible to run the details collection stage only, saving the collected results to a file, which can then be uploaded to the SCC in a separate run, potentially on a different system.

This allows for customer deployment scenarioes where the system that has access to be able to collect details from the hypervisor backends may not have internet access to be able to upload the collected details to the SCC; the details collection can phase can be run on an internal system with the necessary access, with the saved collection results then being transferred to another system with internet access that can run the upload phase.

Reviewing and sanitizing the collected results¶

This separation of the collection and upload phases also allows the collected results data to be reviewed and potentially sanitised, e.g. hostnames and VM names can be changed.

However, certain values, such as the VM UUIDs and Libvirt host system properties and identifiers should not modified as these values are used to cross reference collection details with any associated subscriptions in the SCC.

CONFIGURATION MANAGEMENT¶

The configuration settings, which must be in YAML format, can be specified as:

•

a single config file via the --config option.

•

a directory containing a set of YAML files (with .yaml or .yml suffixes) via the -config-dir option.

If a configuration directory is specified then any YAML files found under that directory, not traversing sub-directories, with .yaml or .yml suffixes, will be processed in lexical sort order, merging their contents together.

If a configuration file was specified, it's contents will be processed last and merged over any existing configuration settings.

This scheme allows for configuration settings to be split up into multiple files, e.g. credentials can be specified in one file, and the hypervisor backends in one or more files. Additionally specific config settings can be overriden by an explicitly specified config file.

When splitting the hypervisor backend details among multiple files, the backends lists in each file will be merged together to form a single combined list; exact duplicates will be ignored but partial duplicates will result in errors.

ACCESS AND OWNERSHIP¶

For security reasons only the non-root user that is running the scc-hypervisor-collector command should be able to access the specified configuration files.

CONFIGURATION VALIDATION¶

The --check option can be utilised to check if the specified configuration settings are valid, or will report any errors that it detected.

SUPPORTED HYPERVISORS¶

The following hypervisor types are supported:

•

VMWare vCenter (type VMware)

•

Libvirt (type Libvirt)

Each hypervisor type has specific configuration settings that must be provided to permit the relevant details to be retrieved; these settings are documented in scc-hypervisor-collector(5).

HYPERVISOR DETAILS RETRIEVAL¶

The gatherer Python module provided by the virtual-host-gatherer(1) command is used to retrieve the details from the configured hypervisors.