As you wish. I have made python script for my customer:
https://github.com/psztoch/virt-report
Nevertheless, I think the second version of my patch for the virsh list
is simple and traightforward, and falls within the scope of a simple
low-level virsh tool. And of course should be merged into trunk.
On 09.05.2017 13:25, Andrea Bolognani wrote:
On Mon, 2017-05-08 at 09:16 +0200, Przemysław Sztoch wrote:
Dear Michal and Pavel,
We cover about 100 clients who have their own and simple CentOS KVM
installations.
Their technical skills are far from writing python scripts. They expect
simple solutions.
They don't necessarily have to write the Python script
themselves, though :)
Talking to our helpdesk, I found that 70% of libvirt and virtualization
problems are:
A) lack of autostart activation on critical guests; then occasional
failures and reboots affect lack of automatic startup of key services,
B) frequent overcommiting of allocated virtual processors and memory due
to the lack of basic planning and addition operations of local admin
stuff :-(,
C) misconfiguration of qemu-agent, which affects many problems with safe
restart, snapshot, backup, etc. (the "Time" column is a perfect
diagnostic here)
D) leaving unnecessary snapshots that lie unused after many months,
E) live migration attempts that fail to put domain in a transient mode
leave the guests disappearing in unexplained circumstances after kvm
host restart :-)
Virtually all the above problems of everyday life, our helpdesk is now
able to diagnose by command:
virsh list --details --managed-save
By the way, they can easily update the documentation with one compact list.
I do not understand your dislike for the proposed changes. All the
members of our team and teams of our partners have been very
enthusiastic about the new functionality.
You govern, so you have to decide. ;-)
The problem with your proposal is that it doesn't fit
neatly in a generic tool like virsh.
My suggestion would be to implement the script yourself,
then ship it to your clients and instruct them to run
# virt-diagnostics.py
or whatever you end up calling it to obtain the
information you care about.
Doing so will allow you to have plenty of freedom when
it comes to tailoring the output for your specific needs
instead of having to keep the tool generic, which you
would have to do if you wanted it to be shipped with
libvirt, and it won't be any harder for your clients to
run it.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
