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

How to find the slowness on knife vsphere vm vmdk add? #508

Open
rdeavila opened this issue Jan 12, 2021 · 1 comment
Open

How to find the slowness on knife vsphere vm vmdk add? #508

rdeavila opened this issue Jan 12, 2021 · 1 comment
Labels
Status: Untriaged An issue that has yet to be triaged.

Comments

@rdeavila
Copy link

Hello!

Scenario:

I'm seen a very annoying slowdown on the knife vsphere vm vmdk add command. In one datacenter, this command runs with no delay; in another, I've seen times between 4 and 10 minutes to complete. Using -VVV I found the slowness: it's on vsphere_vm_vmdk_add.rb between lines 85 and 96.

Of course, the problem is on my vsphere, but how can I find who is the real culprit on vsphere API? How I debug this file using my production server?

Thanks.

@rdeavila rdeavila added the Status: Untriaged An issue that has yet to be triaged. label Jan 12, 2021
@swalberg
Copy link
Collaborator

Hi, that code is not great. It's looking at all the files in the datastore to find ones associated with the VM, and each trip through the loop is probably going to involve an API call back to vsphere. You could validate this with some puts lines, say right before that if on line 91.

If you can run the command within the datacenter rather than remotely that'll speed things up. Someone more conversant with the vsphere API might know a way to get the same data but faster. Or maybe the search helpers could be used to reduce the round trips back to the server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Untriaged An issue that has yet to be triaged.
Projects
None yet
Development

No branches or pull requests

2 participants