VMWare platforms, Citrix XenServer, HyperV, oVirt, Redhat, KVM/libvirt, OpenVZ, AIX HMC, Nutanix, Docker, and LXC virtualization platforms can all be discovered directly from the Device42 UI.
While configuring the job, you may elect to have your primary Device42 appliance directly perform the discovery, or you may designate a remote collector to run each task.
Setting up VMware/Citrix Xenserver/oVirt/KVM/LXC auto-discovery
From Discovery > Hypervisors/*nix/Windows, you can add a hypervisor discovery job that can connect to and gather host and guest VM details. Options are as follows:
Job name : A name of your choosing to identify the autodiscovery job.
Remote Collector : Optionally, run the discovery job from the chosen remote collector instead of the main appliance.
Platform : Choose Vmware, Citrix XenServer, oVirt Server, KVM/libvirt, Docker, LXC, etc.
URL Prefix: : This will be https in most cases. But, if you have changed it, you have the option to switch it to http.
Server : This is the FQDN or IP of the vCenter server or the ESX server. If using FQDN, device42 should be setup for DNS resolution(vm console, option 1)
Port : This will be 443 by default. Only change if you have changed it.
Username & password: self explanatory. Use username with permission to view all the hosts and virtual machine inventory info. For oVirt the username is most probably in the format of username@domain, e.g. admin@internal
Please do not set up an auto-discovery / scan using critical [production] account credentials! Please create a separate, dedicated account to use only for discovery
Doing so, depending on permissions granted & configured password policies could result in account lock-out, therefore causing an otherwise completely avoidable outage.
Strip domain suffix : Checking this will strip domain suffix from host and VM names.
Toggle service level on vm power state : If a VM is powered off, checking this will mark that virtual machine as “Not in Service”.
Get Guest OS Info : Grabs the guest OS information for a VM. This is not as detailed as a WMI/SSH level discovery from a machine level. Available for vmware only for now.
Debug Level : Debug On for extra debug info, useful for a support ticket.
VM name to use : if the virtual machine has different name on the host and as found from the tools, you can choose which name should be used while adding/updating the VM in device42. Available for vmware only for now.
Add multiple VM names as alias : If VM name on host and as found from tools doesn’t match, you can add second name as device alias by checking this option. Available for vmware only for now.
Track VM name change : Added in v5.8.0 to track any changes to the VM name. This applies if name is changed on an existing VM(verified by UUID). If the new name already exists in the system – it will be ignored.
Action for VM not found : You can choose various actions for a VM not found. Discussed below in more detail.
Last status : Last run task status.
Run report: This will record what has changed in the last task.
Schedule for auto-discovery: You can schedule the discovery to run at certain times.
Run VMware discovery
Upon save(if you haven’t scheduled the discovery), you can run it from list, view or edit page using “Run now” button or link.
“Action for VM not found” details — What happens to VM that has been deleted from a host?
This section allows you to choose one of three actions for a stale [deleted / no longer discovered] VM.
- Remove Host Association. This is default. Host association is removed.
- Change Service Level. You can change the service level for stale VMs. This way it is easy to filter and report on these.
- Delete VM. You can choose to outright delete the VM.
Under the hood
Device42 uses VMware APIs and the open source library pyvmomi.
You can schedule the auto-discovery to run on a recurring basis. Specifically, you can choose to have it run on certain days of the week and at a specific time each day!