Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: vSphere Support #928

Open
netgun opened this issue Mar 11, 2024 · 15 comments
Open

[Feature]: vSphere Support #928

netgun opened this issue Mar 11, 2024 · 15 comments
Labels
enhancement New feature or request

Comments

@netgun
Copy link

netgun commented Mar 11, 2024

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 netgun added the enhancement New feature or request label Mar 11, 2024
@ddutt
Copy link
Member

ddutt commented Mar 12, 2024

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?

@tgupta3
Copy link
Contributor

tgupta3 commented Mar 18, 2024

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 ?

@ddutt
Copy link
Member

ddutt commented Mar 18, 2024

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

@tgupta3
Copy link
Contributor

tgupta3 commented Mar 18, 2024

@ddutt I meant I can implement this.

@netgun
Copy link
Author

netgun commented Mar 18, 2024

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

@ddutt
Copy link
Member

ddutt commented Mar 18, 2024

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.

@tgupta3
Copy link
Contributor

tgupta3 commented Mar 18, 2024

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.

@ddutt
Copy link
Member

ddutt commented Mar 19, 2024

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

@tgupta3
Copy link
Contributor

tgupta3 commented Mar 19, 2024

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.

@ddutt
Copy link
Member

ddutt commented Mar 21, 2024

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

@tgupta3
Copy link
Contributor

tgupta3 commented Mar 29, 2024

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
Copy link
Contributor

tgupta3 commented Apr 28, 2024

@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 ?

@ddutt
Copy link
Member

ddutt commented Apr 28, 2024

@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?

@tgupta3
Copy link
Contributor

tgupta3 commented Apr 28, 2024

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

@ddutt
Copy link
Member

ddutt commented Apr 28, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants