I tried to create a VM on the demo site, and got a nice Ruby error message next to the VM's name on the 'Machines' page: undefined method `+' for nil:NilClass
Still, I'm very excited about this!
If anyone from the project reads this: Where is the appropriate place to request support for an additional GNU/Linux distribution? I would love to get GNU Guix running on this.
Edit: It seems that I have jumped the gun with my enthusiasm for this project. They will be selling proprietary re-licensed versions as a reward and require copyright assignment for contributions.
VirtKick, please reconsider your decision to require copyright assignment. I want my contributions to the free software community to remain free.
So selling proprietary versions isn't your goal, but allowing the code to be used in proprietary versions is?
You're walking a very fine line here. One so thin I wouldn't fault anyone who said it doesn't even exist.
Of course, I was just wondering where a ticket could be created so that it's on the record as a feature request.
>We currently have virtkick-starter, a bunch of scripts that set everything up.
Perfect. I'll have a look. Thanks!
Edit: I think we have a misunderstanding. I would like to use VirtKick to provision Guix VMs, not just install VirtKick on Guix.
And you don't feel that the AGPLv3 ensures that...? Or you mean "I don't want my contributions to be distributed under any other license"?
For programs like this, I see little benefit of AGPL over GPL, since the main use-case will be in-house deployments. I can't see how anyone would deploy something like this on the backend, where if you made an in house-fork with bug fixes to support your proprietary infrastructure, you'd have to publish the patches for the wider community. It seems like a big red flag to me.
It's good enough for Linux.
It is a pain to configure, but that's the price you pay for flexibility, future-proofing (scalability) and its' true community development model.
* No virt-manager with SPICE, networking configuration, and other features
* No virt-install for very easy creation of VMs, even straight from distro repository URLs
* No virsh for command-line management
* In general, no seamless use of any of the vast ecosystem of tools around libvirt
Is the only advantage that it supports Docker? In that case, why not just add support for Docker into libvirt, and Docker images into virt-install? Is the advantage that it's a web UI for libvirt? There are certainly plenty of those already, but I guess creating another one is fine. I really don't see the use-case.
* used libvirt and the various tools you mentioned for managing VMs
* used the libvirt API to help write vagrant-libvirt [0]
Existing libvirt clients, at least those that we know of, aren't super reliable though. libvirt stucks when there's too much happening on the HV, or denies jobs without even trying (e.g. when a pool has async jobs). A backend that schedules tasks for background execution is needed for that (and we have it), so even now we're not "just" a frontend for libvirt.
The use case is a very simple panel with zero virt knowledge needed to start.
Thanks for your comment.
I would certainly prefer that virtkick was 'just a frontend' for libvirt. Then the people who are making use of virtkick can seamlessly rely on the huge amount of existing software that supports libvirt. You can provide a REST API that is translated to the existing libvirt API rather than replacing it.
If you have task-scheduling improvements for libvirt, they should be upstreamed rather than only exist in your software, so everyone can benefit from them.
Are the extras like monitoring 3rd party integrations that I'll have to pay for, or actual features of VirtKick?
External monitoring integration, and off-site status page, will be actual features of VirtKick. Think of VirtKick is a 1-click installable panel that you can use both on your desktop and as a VPS provider. Instead of paid features, we want it to be forever free - instead, we aim to be crowdfunded. https://www.indiegogo.com/projects/virtkick-take-cloud-back
Things get crazy here (in a good way). You could create federation where you allow remote hypervisor management from a central authority (your app). #ArchiveTeam needs their VM running for the latest web property shutdown? Here, have access to my overpowered home router to run a few tiny VMs to help the cause.
Knocked it out of the park here guys (and/or gals)! Awesome job.
VirtKick is a self-hosted DigitalOcean. Both are very simple IaaS (but it's you who provide the "I" with the former)
Does it explain?
My follow-up then would be how would this compare to OpenStack? If they serve the same purpose, where do you want to differentiate from OpenStack?
Because DigitalOcean, basically, is a way to get VMs without self-hosting them!
I honestly value DO for the service of providing VMs, and I don't care to run my private VMs. We also have dedicated servers, which run docker directly.
VirtKick is like DigitalOcean or Linode - they are focused on machines (and containers, that you think of as machines). You install it on your Linux desktop (for localhost hacking), or home or dedicated server (for something more).
Will try to express it a little bit better. Thanks for your feedback.
This is because I don't use port 22 for SSH. Can I fix this easily?