It's the usage, not the internals, I find overcomplicated.
Every time I've looked at it, I've just ended up writing a small shell script to do what I needed instead rather than having to deal with the convoluted XML config and read through massive amounts of documentation.
If you're writing or editing XML, then you're probably doing it wrong (which to be fair could be a problem with the documentation). You should probably be using commands like:
virsh start MyGuest
To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.
In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.
I added a libvirt backend to libguestfs (previously we were managing KVM processes by hand). The change is completely transparent to libguestfs users.
> To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.
All of which adds more complexity to do something I can do trivially without libvirt.
I might just not be the right target for it, given that I have the luxury of being able to use only LXC and OpenVz, and in both cases creating and managing VM's with the tools provided is extremely easy.
> In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.
Of course as someone using mostly LXC and OpenVz, to me Vagrant also seems totally over-engineered for what it does. It's at least a factor of 10 larger than what we use to build and deploy our entire production clusters. I'm very happy I don't have to deal with that kind of complexity just to get some dev environments set up.
Comments
It's the usage, not the internals, I find overcomplicated.
Every time I've looked at it, I've just ended up writing a small shell script to do what I needed instead rather than having to deal with the convoluted XML config and read through massive amounts of documentation.
If you're writing or editing XML, then you're probably doing it wrong (which to be fair could be a problem with the documentation). You should probably be using commands like:
To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.
I added a libvirt backend to libguestfs (previously we were managing KVM processes by hand). The change is completely transparent to libguestfs users.
> To create guests: virt-install, virt-manager, Boxes, Heat, OpenStack or one of the many other libvirt users. None require XML editing.
All of which adds more complexity to do something I can do trivially without libvirt.
I might just not be the right target for it, given that I have the luxury of being able to use only LXC and OpenVz, and in both cases creating and managing VM's with the tools provided is extremely easy.
> In any case, that's not an issue for the topic here. The Vagrant developers will certainly need to read up some libvirt API documentation, but once they have made the sensible decision to use libvirt, then that will be completely hidden inside Vagrant, and wouldn't affect end users of Vagrant in any way.
Of course as someone using mostly LXC and OpenVz, to me Vagrant also seems totally over-engineered for what it does. It's at least a factor of 10 larger than what we use to build and deploy our entire production clusters. I'm very happy I don't have to deal with that kind of complexity just to get some dev environments set up.