On Thu, Oct 28, 2010 at 09:02:31AM -0600, Eric Blake wrote:
On 10/28/2010 07:13 AM, Daniel P. Berrange wrote:
> On Thu, Oct 28, 2010 at 03:00:45PM +0200, Daniel Veillard wrote:
>> To ease debugging this trivial patch allows to find what was compiled
>> in in the local version of libvirt, this doesn't work for remote access
>> but that's probably sufficient. With the patch I get on my machine:
>>
>> paphio:~/libvirt/tools -> ./virsh --version
>> Virsh command line tool of libvirt 0.8.4
>> See web site at
http://libvirt.org/
>>
>> Compiled with support for:
>> Hypervisors: Xen QEmu/KVM UML OpenVZ LXC ESX PHYP Test
>> Networking: Remote Daemon Network Bridging Netcf Nwfilter
>> Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM
>> Miscellaneous: SELinux Secrets Debug Readline
>> paphio:~/libvirt/tools ->
>>
>> instead of just "0.8.4"
>
> Hmm, if any script is running the current 'virsh --version' command
> to get the version number then this will break their usage. I think
> we should require a different and/or extra flag to print the
> extended data. --version is not a great place since this isn't
> really version information.
>
We already have:
$ virsh version
Compiled against library: libvir 0.8.2
Using library: libvir 0.8.2
Using API: QEMU 0.8.2
Running hypervisor: QEMU 0.12.5
Can we just beef that up, and leave 'virsh --version' as the short
information?
Same name but different information. --version is telling you about
the virsh binary version, while 'version' is telling you about the
open connection to libvirt. Putting the virsh binary build options
in 'version' would be somewhat misleading, because they don't
reflect the open connection
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|