10:17 a.m.
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
12:05 p.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
12:20 p.m.
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 :|
1:08 p.m.
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
2828
days inactive
2828
days old
3 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Kashyap Chamarthy -
Martin Kletzander -
Michal Privoznik