[libvirt] CLI management tool
Dear list, you might have seen a discussion about virsh, and adding some new features to it [1]. While the feature was rejected, it got me thinking. What options do we offer for sysadmins that: a) want to stay in command line b) want higher level mgmt of their domains c) yet want to manage a single host Basically, virsh is just too low level for some operations (and using it in non-interactive mode from a script can mean hundreds of connections). Then we have virt-manager, which suits b) and c), but it's not a CLI tool. Therefore I was thinking whether we should start a new project on the top of libvirt that would fit all three points. Personally, I've never been a sysadmin, so perhaps I am not the best one to write the tool. But I'm open for suggestions. What do you think? Michal 1: https://www.redhat.com/archives/libvir-list/2017-May/msg00051.html
On Thu, May 11, 2017 at 09:17:39AM +0200, Michal Privoznik wrote:
Dear list,
you might have seen a discussion about virsh, and adding some new features to it [1]. While the feature was rejected, it got me thinking. What options do we offer for sysadmins that:
a) want to stay in command line b) want higher level mgmt of their domains c) yet want to manage a single host
Basically, virsh is just too low level for some operations (and using it in non-interactive mode from a script can mean hundreds of connections). Then we have virt-manager, which suits b) and c), but it's not a CLI tool. Therefore I was thinking whether we should start a new project on the top of libvirt that would fit all three points.
Personally, I've never been a sysadmin, so perhaps I am not the best one to write the tool. But I'm open for suggestions.
What do you think?
Given the deprecation of TUI mode of virt-manager, I'd guess it's not something that would be so beneficial. I'm not saying people don't want it, but the market is so spread out that every few people will have so different usage cases that it's more advantageous for each one of them to cook up a small tool for their usage. I think the bindings we provide are sufficient to simply create your own TUI with some easy TUI library. That's why there are things like virt-manager.el for emacs, nemu as a new ebuild in gentoo, and I believe many others that I don't remember. Some of them are definitely just for fun, but there are some that probably people wanted to use. Adding more stuff to add functionality to (considering how many places we have already) could make the code worse as many people are not cleaning up after themselves already. But if you want to do that, I'm not going to stand in your way ;) This is just my personal opinion on what you asked about.
Michal
1: https://www.redhat.com/archives/libvir-list/2017-May/msg00051.html
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, May 11, 2017 at 09:17:39AM +0200, Michal Privoznik wrote:
Dear list,
you might have seen a discussion about virsh, and adding some new features to it [1]. While the feature was rejected, it got me thinking. What options do we offer for sysadmins that:
a) want to stay in command line b) want higher level mgmt of their domains c) yet want to manage a single host
Basically, virsh is just too low level for some operations (and using it in non-interactive mode from a script can mean hundreds of connections). Then we have virt-manager, which suits b) and c), but it's not a CLI tool. Therefore I was thinking whether we should start a new project on the top of libvirt that would fit all three points.
Personally, I've never been a sysadmin, so perhaps I am not the best one to write the tool. But I'm open for suggestions.
What do you think?
A long long long time ago, I did some work on creating an extensible replacement for virsh. The idea was to provide a minimal, pluggable framework for a CLI tool using the GObject framework. Commands would emit structured objects, and we'd have plugins to translate it to plain text, JSON, XML, etc. The commands themselves would also all be plugins, likely written in a non-C language like Python/JavaScript/blah. A key idea is that this tool would *not* simply target libvirt APIs, it would be a more general virt shell that would include other tasks. For example, 'virt-install' would just be a command plugin, as would various libguestfs commands, and virt-top, etc etc By having commands written in a high level language, it was inteded that sysadmins would be able to provide custom stuff to automate jobs that they particularly cared about I never got it developed far enough though to be worth publishing it. Not even sure what happened to the code I did right... Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, May 11, 2017 at 09:17:39AM +0200, Michal Privoznik wrote:
Dear list,
you might have seen a discussion about virsh, and adding some new features to it [1]. While the feature was rejected, it got me thinking. What options do we offer for sysadmins that:
a) want to stay in command line b) want higher level mgmt of their domains c) yet want to manage a single host
Basically, virsh is just too low level for some operations (and using it
I'd guess probably you're thinking about advanced features like CPU pinning, NUMA, etc. But for the most majority of cases, is `virsh` really that much of a low-level tool for administrators? What do I know...
in non-interactive mode from a script can mean hundreds of connections).
You mean, these kind of hundreds of connections could be avoided when using proper APIs, where you open a connection and do multiple thing at once. e.g.: ------------------------------------------------------------- #!/usr/bin/python import libvirt import sys conn = libvirt.openReadOnly('qemu:///system') if conn == None: print 'Failed to open connection to the hypervisor' sys.exit(1) domains = conn.listAllDomains(0) # Perform other useful operations via libvirt API [...] ------------------------------------------------------------- Hmm, that's a valid point.
Then we have virt-manager, which suits b) and c), but it's not a CLI tool. Therefore I was thinking whether we should start a new project on the top of libvirt that would fit all three points.
Personally, I've never been a sysadmin, so perhaps I am not the best one to write the tool. But I'm open for suggestions.
What do you think?
[...] -- /kashyap
participants (4)
-
Daniel P. Berrange -
Kashyap Chamarthy -
Martin Kletzander -
Michal Privoznik