suzieq icon indicating copy to clipboard operation
suzieq copied to clipboard

[Feature]: vSphere Support

Open netgun opened this issue 11 months ago • 15 comments

Suzieq version

0.17.0

Install Type

container

Feature type

New component

Use case

Why not support the Distributed Virtual Switch that exists within vSphere? There could be a vast source of knowledge to be brought into SuzieQ. And for those that run a Virtualized Datacenter without access to the physical devices, this could be huge

Proposed functionality/solution

If you could read the Virtual Machine and associated network topology attached to it, you would have details on how all virtual machines are connected to the Virtual Switch level.

External dependencies

none

Additional Context

_

netgun avatar Mar 11 '24 22:03 netgun

Thank you for the suggestion @netgun . This is very useful, no doubt. But this will be a massive effort, as I see it. We have to acquaint ourselves with VMWare API, which we have no way to test, as we can't purchase VMW products :).

What help can you provide us?

ddutt avatar Mar 12 '24 12:03 ddutt

I'm happy to take this as we already have a lot of VMware deployments with & without NSX that I can use to test the code. In return, it would also be beneficial for us to observe the lifecycle of a VM.

Are we just looking to discover what vms are connected to which dvs and which portgroup ?

tgupta3 avatar Mar 18 '24 06:03 tgupta3

What do you mean by "'m happy to take this on", @tgupta3 ?

ddutt avatar Mar 18 '24 13:03 ddutt

@ddutt I meant I can implement this.

tgupta3 avatar Mar 18 '24 15:03 tgupta3

I am happy to help with anything that I can. I am not a developer but can help with things like docs and can even try to get technical questions answered by the developers.

Docs are here https://developer.vmware.com/apis

netgun avatar Mar 18 '24 16:03 netgun

Fantastic @tgupta3 , happy to help you with this. @netgun if you can help test, that'd be great.

First thing we need to do is define what is the information we want to save.

ddutt avatar Mar 18 '24 17:03 ddutt

IMO from troubleshooting point of view two things are very useful

  1. If a VM existed at a point in time and if it was which segment and DVS it was on and also the vcenter it was on ?
  2. The discovered IP for that VM, and maybe other metadata like creation date and template.

tgupta3 avatar Mar 18 '24 18:03 tgupta3

@tgupta3 So, what API calls are necessary for each? Whats the output of each of those API calls? We can start there

ddutt avatar Mar 19 '24 11:03 ddutt

I think this is a good example. It would look very similiar except use content.viewManager.CreateContainerView on vim.DistributedVirtualSwitch.

Once you have all the DVS, it's just a couple of for loops to iterate over the portgroups and then vms to get individual vm. The metadata from the vm can be extracted using the objects defined here . I think the discovered ip address is available in vim.vm.Summary.GuestSummary) but I will have to double check.

tgupta3 avatar Mar 19 '24 23:03 tgupta3

Can you put together a list of fields you'll capture, @tgupta3 ?

ddutt avatar Mar 21 '24 14:03 ddutt

I think 2 tables would be a good starting point

  1. VMs
  • VM ID: Unique identifier for the VM (this is mostly useful for log analysis)
  • VM Name: Name of the VM.
  • VM State: Current state of the VM denoted as ENUM
  • Host ID: Identifier of the host machine on which the VM is running.
  • Operating System: OS installed
  • CPU Allocation: CPU specs
  • Memory Allocation: Memory specs
  • Creation Date: Date and time when the VM was created.
  1. VM interfaces
  • Interface ID: Identifer of the interface
  • VM ID: Identifier of the VM
  • MAC Address: MAC address
  • IP Address(es): IP address(es) associated with the network interface.
  • Connected Port ID: Identifier of the port on the virtual switch to which this interface is connected.
  • DVS: Name or ID of the DVS
  • Status: Operational status

I think with this information, we would be able to construct what the state of the environment looked like. Do you think we would be able to extend it to talk to the network device information to trace the path end to end rather than just terminating on the port of the TOR ?

tgupta3 avatar Mar 29 '24 00:03 tgupta3

@ddutt Can you help me out a bit with how to structure. I was able to write the base layer code to connect and fetch data from vcenter, but i'm having issues on how to fetch data for each vm. I noticed in the `suzieq/config/*.yaml, usually the commands given fetches all data. However in the case of vcenter, it's a two step process

  1. Get all Vms list
  2. Get details about those vms or do a for each.

The API is documented here

Is there an example I can refer to that would help me with this ?

tgupta3 avatar Apr 28 '24 18:04 tgupta3

@tgupta3 IMO, vCenter needs to be treated as an inventory source which is polled for a list of VMs and their IPs, and then you poll each VM like you would a server. Does this make sense? Look at the netbox code (suzieq/poller/controller/source/netbox.py) for modelling vCenter as an inventory source. each VM will then show up as a device under device table, with interfaces, addresses and such. Does this make sense?

ddutt avatar Apr 28 '24 20:04 ddutt

Great, that's a good idea. Let me go through that, will reach out if I run into issues.

tgupta3 avatar Apr 28 '24 21:04 tgupta3

@tgupta3 i highly recommend you join the SuzieQ slack. Interactions can be much faster plus others will pitch in.

ddutt avatar Apr 28 '24 22:04 ddutt