3 ms·

So what exactly is the advantage of using this layer over the existing libvirt ecosystem? If this is supposed to manage your VMs for you instead of you using th

by catern 12y ago

So what exactly is the advantage of using this layer over the existing libvirt ecosystem? If this is supposed to manage your VMs for you instead of you using the existing libvirt tools, I can see a number of disadvantages. * 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.

sciurus 12y ago
As someone who has * used libvirt and the various tools you mentioned for managing VMs * used the libvirt API to help write vagrant-libvirt [0] I feel that libvirt is a useful (albeit quirky) building block but not something you want to interact with directly. Those tools you mentioned aren't ones I'd generally recommend using. You want to have tools with a higher-level of abstraction that can bring in more functionality that is available in just libvirt and provide better interfaces on top of that combination. There's a reason the OpenStack project created Nova, Glance, Neutron, etc. [0] https://github.com/pradels/vagrant-libvirt https://github.com/pradels/vagrant-libvirt
Nowaker 12y ago
What one regards as a feature, other regard as misfeatures. If you like virt-manager, then VirtKick isn't really for you. We value a simple UI more than virt-manager, and REST API more than virsh. We don't say your way is wrong. It's just more difficult. 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.
- catern 12y ago
  > so even now we're not "just" a frontend for libvirt. 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.

by catern 12y ago

sciurus 12y ago

As someone who has * used libvirt and the various tools you mentioned for managing VMs * used the libvirt API to help write vagrant-libvirt [0] I feel that libvirt is a useful (albeit quirky) building block but not something you want to interact with directly. Those tools you mentioned aren't ones I'd generally recommend using. You want to have tools with a higher-level of abstraction that can bring in more functionality that is available in just libvirt and provide better interfaces on top of that combination. There's a reason the OpenStack project created Nova, Glance, Neutron, etc. [0] https://github.com/pradels/vagrant-libvirt https://github.com/pradels/vagrant-libvirt

Nowaker 12y ago

What one regards as a feature, other regard as misfeatures. If you like virt-manager, then VirtKick isn't really for you. We value a simple UI more than virt-manager, and REST API more than virsh. We don't say your way is wrong. It's just more difficult. 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.

catern 12y ago
> so even now we're not "just" a frontend for libvirt. 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.