-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
salt-cloud vsphere cloning and creating vm's #17061
Comments
looks like I caused this issue. I'll take a look. |
to work around this you can set "deploy: False"
|
@steverweber Thanks for the quick PR! @ingwa Can you give this fix a try when you have a moment? I am also backporting the fix to the 2014.7 branch because it looks like that code was changed there as well. |
Actually, I was looking at the wrong branch. Looks like this bug is only on develop, so I won't be backporting the PR. My mistake! |
@steverweber Hi Steve, I did that and the vm successfully created with a nice output of all the fields. Only thing is salt doesn't appear to have installed. Versions:
|
/ salt is not installed on the new system because deploy: False / if you reinstall salt using the latest develop branch it will have the fix so you can use deploy: True. Or you could manualy update your salt code with this fix. I havent had a chance to test Deploy: True, please let me know if you get it to work. |
It's not related to the original question, but the vsphere provider does not use the ssh_username and the ssh_password keywords. It uses the template_user(name)? and template_password keywords. At least it not worked for me to use ssh_username. And even there were no default as in any other provider. |
Seeing the code, isn't a patch like this also needed to make it run? I'm really just curious. diff --git a/salt/cloud/clouds/vsphere.py b/salt/cloud/clouds/vsphere.py
|
Thanks, I missed that. |
Hi guys, appreciate all your input! @steverweber thanks for making the updates, seems we're on the way there. My latest version is:
@mochrul thanks for your input re the passwords. I now have this in my ubuntu.conf profile:
When I run the create function, it creates successfully, machine spins up and then it tries to connect. I'm getting this:
Anything I've done? (corrected spelling in config) |
FYI I have also tried with just user: and password: in the config however the connection debug always states it's using "None". |
Ok, I did some more testing and it seems the template_user: is the correct format for the username, however for some reason the password won't get taken. Here's the output from the debug:
I have successfully logged into the ssh client after the machine spun up manually using the same credentials in the input file. I trimmed it up too by removing ssh_username, etc. |
thanks for testing this. I think I'll take a look tomorrow. |
looking at the source... this wont work... the code will need to be changed :( I might take the time to migrate the code to use: or pass 'has_ssh_agent' to the deploy method so the password will take...
|
@steverweber appreciate you looking into this. Once it's all up and running I'll try work on a detailed example for the documentation. |
sounds good. I'll clean up the code a little so it can take in:
I'm tempted to deprecat
|
I would support deprecating |
Something else that I observed yesterday with all my tests. I notice that part of the command to create a new vm is to define it's name, salt-cloud -p profilename newname. Newname is then used to create a pre-authorized key for salt-key, however when the template vm spins up it's host name is generic, and salt then registers the old hostname from the vm, and places it in unapproved. Secondly, even though I defined:
I tried setting this in the profile, provider, and cloud configs however nothing would allow overriding the default "salt" local network name. My next bet is to perhaps write my own startup sh script that pulls the bootstrap, then does a rename on the hostname to get the new name for the vm and use that instead, and then restart salt, but I am wondering isn't this done somehow already? |
FYI, the tests I performed were after applying the hot fix directly to my salt code and running it again. It did work with the overrides in place, but really appreciate you all looking into this to get it working. I have a few cloud systems I'm testing but one step at a time hehe :) |
@steverweber I see you have a commit referencing this issue, but it doesn't appear to be related to a pull request. Are you still working on that, or did it just get missed? |
Sorry, Its been one of them weeks... Had no time. I can say the second week
|
Not a problem at all @steverweber! I just wanted to check in. Thanks again for all of your contributions! |
The vsphere driver is on a deprecation path and will be officially removed in Salt Carbon (see #24487 and #24504). As such, we'd recommend moving to the new vmware driver. Since we have a much more robust and clean driver, we won't be spending time cleaning up bugs for vsphere. However, we will of course be accepting fixes from community members as they are submitted. |
@rallytime I think this issue can be closed now. |
cheers! |
Hi, Best Regards |
Could you please confirm that this link is deprecated: https://docs.saltstack.com/en/latest/ref/clouds/all/salt.cloud.clouds.vsphere.html |
@molixrawdi Correct - the vsphere driver is officially on a deprecation path and will be removed from Salt in the Carbon release. The VMWare driver in Salt-Cloud should be used instead: |
Hi @rallytime many thanks for the update, Am I correct about the two points I made earlier? (1-Create Virtual machine, 2- Clone virtual machine)? By mentioning the vmware drivers as replacement, Am I correct in assuming by this you mean 'pyVmomi' = https://pypi.python.org/pypi/pyvmomi Best Regards |
@molixrawdi - There is a salt-cloud driver named Here's the salt-cloud driver I am referring to: https://github.com/saltstack/salt/blob/2015.8/salt/cloud/clouds/vmware.py Does that help clear things up? |
@rallytime Thanks again, so the vmware.py comes with salt-cloud which I have so far managed to install using pip install salt-cloud? (Sorry for asking many questions and I truly appreciate your help and time), finally about my two assumptions are they correct! They are: 1- Create a virtual machine via template file, using salt-cloud/pyVmomi, via vcenter only as vsphere is deprecated. |
@molixrawdi Yes, the vmware.py driver comes with salt-cloud. That driver is how salt-cloud interacts with/connects to your VMWare installation. How did you install salt? Depending on your operating system, salt-cloud is either included by default with your salt installation, or it is an extra package taht you can install. You could use pip as well if you want, but it might already be available. Also, what version of salt are you running? (Please post the output of I guess I don't understand what you're stating with your assumptions. You can create and clone a virtual machine with a template file with the vmware driver that comes with salt-cloud. But before you do that you need to install pyVmomi, because the salt-cloud vmware.py driver uses the pyVmomi driver. From the the top of the vmware driver docs: "The VMware cloud module allows you to manage VMware ESX, ESXi, and vCenter." |
Hi @rallytime
|
I have also a second node for testing running Ubuntu 14.04:
|
I have tested both with multiple commands from salt to ensure that there are no outstanding compatibility issues with libraries or clashes with versions. |
After testing, I came to the conclusion that one must install 'salt-cloud' via 'apt-get' and the salt repository instead of 'pip install' the pip install will fail due to unsolved dependencies. |
@molixrawdi Ok - So the There's a ton of useful information about Salt Cloud in the Salt Cloud Docs. |
Hi there,
I've finally managed to get salt cloud talking correctly to esxi and vsphere in general. Turns out to clone images or create vm's on esxi, you MUST have vsphere center server or similar orchestration management system from them in place to expose those elements of the api. The esxi api does not have that in place.
Having issues now on machine creation, seems there is a string int mixup somewhere:
Here is my profile:
I called it like this:
salt-cloud -p my-ubuntu-vm newlinux -l debug
Any ideas on what I'm doing wrong?
The text was updated successfully, but these errors were encountered: