Salt: feature request: use libvirt as a provider for salt-cloud

Created on 20 May 2014  路  15Comments  路  Source: saltstack/salt

Salt-virt is good and all, but i think it makes sense to be able to use libvirt as a provider for salt-cloud. This would make manageing different providers and local libvirt setups easier to maintain without having to set up something like openstack.

Heres a selective cut and paste from the relevant discussion on #salt irc.

09:57 < mortis> anyone know if its possible / will be possible (in the future) to use libvirt as a provider for salt-cloud?
10:13 < jcockhren> mortis: yeah. salt-cloud was merged into salt
10:13 < jcockhren> you mean like a backport?
10:14 < mortis> jcockhren: yeah, thats really nice, and im thinking ...if you could use salt-cloud with libvirt as a provider, you could manage vms in
the cloud or on your local libvirt setup without having to go for something like openstack
10:17 < jcockhren> mortis: hm. I'm not seeing a libvirt module. I see a runner
10:17 < jcockhren> I don't know/see of any reason why that couldn't be added
10:18 < mortis> hm yeah
10:18 < jcockhren> ah. I see the module
10:18 < mortis> wouldnt it be simpler to relate to only salt-cloud and not salt-cloud and salt-virt together?
10:19 < mortis> just an idea
10:20 < jcockhren> well. the underlying functionality is already persent in modules.virt
10:20 < jcockhren> it'll make sense to build the salt-cloud extras on top of that
10:21 < jcockhren> in fact, that basically how eveything works: built on top of modules
10:21 < jcockhren> as a provider, have salt-cloud make the right calls to module.virt
10:23 < mortis> that would be really cool
10:23 < mortis> i wonder if that is something i should make a github feature request from..
10:23 < jcockhren> yep
10:23 < mortis> ill try, and see what response it gets

Feature RIoT Salt-Cloud

Most helpful comment

Progress wise, I did some cleanups a little while back, so things are more robust, and use more utilities from salt cloud. Still need to make things work with full clones. In short still working on it :)

All 15 comments

Thanks for the request. It does sound like it would make managing local and remote clouds at the same time easier.

I have my eyes on it.

+1 on this

That looks pretty good! Any chance to see this upstream?

+1

The proof of concept still needs quite a bit of cleanup, hoping to get to it one of these days. It's motivating that people would like it :)

Thanks @rklaren, we were saluting you at work today ;)
Really looking forward to testing this!

+1
Very interested in this feature.
I already use salt-cloud, kvm+libvirt, salt-virt (+packer) and it would be excellent to integrate them together.

Progress wise, I did some cleanups a little while back, so things are more robust, and use more utilities from salt cloud. Still need to make things work with full clones. In short still working on it :)

Awesome!

Thank you for your Work on this issue.

Hi! I am really interested in this! I am currently trying to use salt-virt but facing some issues that may be addressed by this 馃槃 is there any ETA for when this will get out of the develop branch?

@dxiri Should be in the Nitrogen release due at the end of May.

We are only just beginning with Saltstack, and are using salt-cloud with VMware already. Super happy with it. However, we are in the pilot phase of moving to Nutanix and AHV. As AHV is essentially KVM, will libvert, and this upcoming integration work with Nutanix? Or perhaps is someone working on a more direct integration to Nutanix's API for Salt-Cloud? Either way, we are keeping a very close eye on this and will be trying it out as soon as available. Thank you for the continued amazing work.

@Maudite I think that question is best answered by @rklaren

@Maudite I would not know for sure. As long as salt-cloud can access libvirtd on a target hypervisor then it could work. Then it depends whether AHV can deal with changes done on a lower level. You might check whether Nutanix recommends/discourages changing things with virsh in hypervisors managed by AHV.

Was this page helpful?
0 / 5 - 0 ratings