[Libvir] virt-manager command line options
by Karel Zak
We need a way how call virt-manager methods without D-BUS. This patch
adds new --show-* command line options.
The --show-* options need to be used together with the --connect
option.
Daniel, I also added an OptionValueError exception. It's not perfect
solution, but I'm not sure what's your favourite way for error messages
in virt-manager when GTK is not initialized yet.
# virt-manager --help
usage: virt-manager.py [options]
options:
-h, --help show this help message and exit
-c URI, --connect=URI
Connect to hypervisor at URI
--no-dbus Disable DBus service for controlling UI
--show-domain-creator
Create a new virtual machine
--show-domain-editor=UUID
Edit a domain configuration
--show-domain-performance=UUID
Show a domain performance
--show-domain-console=UUID
Show a domain console
--show-host-summary Show a host summary
Karel
# HG changeset patch
# User Karel Zak <kzak(a)redhat.com>
# Node ID 3aab017160416137fe3033e13a206303287e5dd9
# Parent 127d61c9062e0ed5662f412f5edbb6c7dbd5582f
add command line option
diff -r 127d61c9062e -r 3aab01716041 src/virt-manager.py.in
--- a/src/virt-manager.py.in Thu Oct 19 13:48:03 2006 -0400
+++ b/src/virt-manager.py.in Wed Oct 25 23:24:24 2006 +0200
@@ -70,7 +70,7 @@ dbus.glib.threads_init()
dbus.glib.threads_init()
import dbus.service
-from optparse import OptionParser
+from optparse import OptionParser, OptionValueError
appname = "::PACKAGE::"
appversion = "::VERSION::"
@@ -102,21 +102,74 @@ from virtManager.remote import vmmRemote
gtk.window_set_default_icon_from_file(icon_dir + "/" + appname + "-icon.svg")
+# maps --show-* to engine methods
+def show_engine(engine, show, uri, uuid):
+ if show=='creator':
+ engine.show_create(uri)
+ elif show=='editor':
+ engine.show_details_config(uri, uuid)
+ elif show=='performance':
+ engine.show_details_performance(uri, uuid)
+ elif show=='console':
+ engine.show_console(uri, uuid)
+ elif show=='summary' or uri:
+ engine.show_manager(uri)
+ else:
+ engine.show_connect()
+
+# maps --show-* to remote manager methods
+def show_remote(managerObj, show, uri, uuid):
+ if show=='creator':
+ managerObj.show_domain_creator(uri)
+ elif show=='editor':
+ managerObj.show_domain_editor(uri, uuid)
+ elif show=='performance':
+ managerObj.show_domain_performance(uri, uuid)
+ elif show=='console':
+ managerObj.show_domain_console(uri, uuid)
+ elif show=='summary' or uri:
+ managerObj.show_host_summary(uri)
+ else:
+ managerObj.show_connect()
+
+# Generic OptionParser callback for all --show-* options
+# This routine stores UUID to options.uuid for all --show-* options
+# where is metavar="UUID" and also sets options.show
+def opt_show_cb(option, opt_str, value, parser):
+ if option.metavar=="UUID":
+ setattr(parser.values, "uuid", value)
+ s = str(option)
+ show = s[s.rindex('-')+1:]
+ setattr(parser.values, "show", show)
+
# Run me!
def main():
optParser = OptionParser()
- optParser.add_option("-c", "--connect", dest="uri", help="Connect to hypervisor at URI", metavar="URI")
- optParser.add_option("--no-dbus", action="store_true", dest="nodbus", help="Disable DBus service for controlling UI")
+ optParser.set_defaults(uuid=None)
+ optParser.add_option("-c", "--connect", dest="uri",
+ help="Connect to hypervisor at URI", metavar="URI")
+ optParser.add_option("--no-dbus", action="store_true", dest="nodbus",
+ help="Disable DBus service for controlling UI")
+ optParser.add_option("--show-domain-creator", action="callback",
+ callback=opt_show_cb, dest="show", help="Create a new virtual machine")
+ optParser.add_option("--show-domain-editor", type="string", metavar="UUID",
+ action="callback", callback=opt_show_cb, help="Edit a domain configuration")
+ optParser.add_option("--show-domain-performance", type="string", metavar="UUID",
+ action="callback", callback=opt_show_cb, help="Show a domain performance")
+ optParser.add_option("--show-domain-console", type="string", metavar="UUID",
+ action="callback", callback=opt_show_cb, help="Show a domain console")
+ optParser.add_option("--show-host-summary", action="callback",
+ callback=opt_show_cb, help="Show a host summary")
(options, args) = optParser.parse_args()
+
+ if options.show and options.uri==None:
+ raise OptionValueError("can't use --show-* options without --connect")
config = vmmConfig(appname, appversion, gconf_dir, glade_dir, icon_dir)
engine = vmmEngine(config)
if options.nodbus:
- if options.uri != None:
- engine.show_manager(options.uri)
- else:
- engine.show_connect()
+ show_engine(engine, options.show, options.uri, options.uuid)
else:
bus = None
try:
@@ -135,19 +188,14 @@ def main():
managerProxy = bus.get_object("com.redhat.virt.manager", "/com/redhat/virt/manager")
managerObj = dbus.Interface(managerProxy, "com.redhat.virt.manager")
- if options.uri != None:
- managerObj.show_host_summary(options.uri)
- else:
- managerObj.show_connect()
+ show_remote(managerObj, options.show, options.uri, options.uuid)
+
# yes, we exit completely now - remote service is in charge
return
except:
logging.warning("Could not connection to session bus, disabling DBus service " + \
str(sys.exc_info()[0]) + " " + str(sys.exc_info()[1]))
- if options.uri != None:
- engine.show_manager(options.uri)
- else:
- engine.show_connect()
+ show_engine(engine, options.show, options.uri, options.uuid)
gtk.main()
if __name__ == "__main__":
18 years, 1 month
[Libvir] Include actual error info in python exceptions
by Daniel P. Berrange
The current python bindings throw a generic libvirtError exception object
whose message merely consists of the name of the method which failed. This
isn't really all that useful to the caller, since they know exactly which
method failed - its the one they just called! The attached patch adds a
binding for virConGetLastError & virGetLastError & pulls this info into
the libvirtError object being thrown.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
18 years, 1 month
[Libvir] Ensure errors are reported against virConnect object
by Daniel P. Berrange
In xend_internal.c there are a large number of places where errors are being
reported without supplying an associated virConnectPtr object. So for example
when calling virDomainCreateLinux, some errors get associated with the
connection object, while others get attached to the global error object.
The attached patch fixes up all places in xend_internal.c which have an
virConnectPtr object available to always pass this object into the the
error reporting funcs.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
18 years, 1 month
[Libvir] Make python binding release GIL when using threads
by Daniel P. Berrange
In the virt-manager app I'm using the python bindings to libvirt for all
operations. For long running operations such as creating new domains, or
saving/restoring domains I fork a background thread to do the call, so that
the main UI / status refresh can carry on working. Except this wasn't working.
The main thread was being blocked for the entire duration of the background
thread. After a lot of nasty debug sessions I discovered that the main
thread was being blocked in the GTK event loop attempting to aquire the
Python GIL (Global Interpreter Lock). The only way this could be occurring
is if the background thread doing the libvirt call held the GIL.
And indeed after looking at the source for the libvirt python bindings it
appears we never release the GIL when calling into the libvirt C apis, so
for the entire duration of virDomainCreateLinux the python interpreter
is completely stopped. Clearly this sucks because virDomainCreateLinux
can take a very long time.
I read up a little on python threading & looked at how PyGTK deals with
this & have come up with a patch to make libvirt release the GIL when
entering a C call & re-aquire it on completion. Indeed, since PyGTK &
GTK are both LGPL, I just copied their C macros straight over.
The patch appears to work - the python interpreter is no longer deadlocked
when calling virDomainCreateLinux (or any other libvirt calls). Unfortuntely
the virtmanager app still deadlocks, because it turns out XenD itself
serializes all SEXPR HTTP requests, but once this is fixed the whole thing
is fully parallelized & works without blocking the app.
Attached the patch - I've not done much python threading before so let
me know if i missed anything / messed stuff up. NB, I also hacked up
the error handling callback so it re-acquires the lock before calling
back into the python.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
18 years, 1 month
[Libvir] Release of libvirt-0.1.8
by Daniel Veillard
There have been a number of bug raised and fixed since the 0.1.7 release:
* Bug for system with page size != 4k
* vcpu number initialization (Philippe Berthault)
* don't label crashed domains as shut off (Peter Vetere)
* fix virsh man page (Noriko Mizumoto)
* blktapdd support for alternate drivers like blktap (Daniel Berrange)
* memory leak fixes (xend interface and XML parsing) (Daniel Berrange)
* compile fix
* mlock/munlock size fixes (Daniel Berrange)
* improve error reporting
The new package is available as usual at
ftp://libvirt.org/libvirt/
thanks to everybody who helped by reporting or fixing bugs !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
18 years, 1 month
[Libvir] Potential problem on NUMA machines
by Philippe Berthault
In the virNodeInfo structure, it's assumed that all nodes of
multiprocessor systems have the same number of sockets. But on NUMA
machines, it's not mandatory that all SMP nodes have the same number of
sockets.
So there is a potential problem when computing the number of processors
by using the informations returned in the virNodeInfo structure.
This problem exists also in Xen (in the "xm info" command) but both Xen
and libvirt are wrong.
18 years, 1 month
[Libvir] virDomainGetInfo returns a false result on IA64 systems
by Philippe Berthault
The maxMem and memory fields of the virDomainInfo structure are false on
IA64 systems.
The problem is in xen_internal.c at lines 1530,1531:
info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * 4;
info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * 4;
It's assumed that page size is 4 KB (* 4) but this isn't correct on a
IA64 system where the page size is variable.
I haven't checked but I suppose this bug exists also with the
virDomainGetMaxMemory and virDomainSetMaxMemory functions.
Regards.
18 years, 1 month
[Libvir] Bug correction in virDomainGetVcpus() function
by Philippe Berthault
In the virXen_getvcpusinfo() function of xen_internal.c source file, the
vcpu number stored in the virVcpuInfo structure is the xen domain id
instead of the vcpu id.
Here the patch of the correction.
--- libvirt-0.1.7/src/xen_internal.c 2006-09-29 10:18:17.000000000 +0200
+++ libvirt-0.1.8/src/xen_internal.c 2006-10-12 11:29:40.000000000 +0200
@@ -1012,7 +1012,7 @@
ret = xenHypervisorDoV2Dom(handle, &op);
if (ret < 0)
return(-1);
- ipt->number = id;
+ ipt->number = vcpu;
if (op.u.getvcpuinfo.online) {
if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING;
if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED;
@@ -1054,7 +1054,7 @@
ret = xenHypervisorDoV1Op(handle, &op);
if (ret < 0)
return(-1);
- ipt->number = id;
+ ipt->number = vcpu;
if (op.u.getvcpuinfo.online) {
if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING;
if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED;
@@ -1078,7 +1078,7 @@
ret = xenHypervisorDoV0Op(handle, &op);
if (ret < 0)
return(-1);
- ipt->number = id;
+ ipt->number = vcpu;
if (op.u.getvcpuinfo.online) {
if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING;
if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED;
18 years, 1 month
[Libvir] [PATCH] libvirt incorrectly reports crashed domains as shutoff
by Peter Vetere
Hi, I've noticed that libvirt seems to report crashed domains as
shutoff. Here's an example:
[root@XXXXX ~]# virsh list
Id Name State
----------------------------------
0 Domain-0 running
27 test03 blocked
34 test01 shut off
36 onetwentyeight blocked
[root@XXXXX ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 356 1 r----- 3655.4
onetwentyeight 36 128 1 -b---- 16.7
test01 34 256 1 ----c- 7.4
test03 27 256 1 -b---- 231.7
The reason is because xen_internal.c does not interpret the additional
shutdown flags when it checks the domain's state. Attached is a patch
which correctly checks these flags and reports the crashed state. I
wasn't sure of the best way to react to the other shutdown flags, so I
just defaulted to "SHUTOFF" for everything else.
Pete
18 years, 1 month
[Libvir] Supporting new Xen 3.0.3 blktap backend for file devices
by Daniel P. Berrange
When defining a guest's block device in the libvirt XML we currently allow
the dev to be backed by either a file or block device in the host system.
This is done by specifying the 'type' attribute when defing the block
device XML.
eg
<disk type='file'>
Or
<disk type='block'>
This is all fine & dandy for Xen 3.0.2, but in 3.0.3 we now have a choice
of drivers for the 'file' backed block devices. We can either use the
traditional loopback mounted system, or the new blktap system. To complicate
things further still, blktap itself has man different drivers - one uses
a raw file with Async-IO, another uses the QCow sparse format with AIO,
and all sort of other possibilities are available...
This means the easy option of just making all file devices use blktap in
3.0.3 is not practical. This in turns means we need to come up with a
way to express the new driver methods in libvirt XML. There are a few
options I can think of :
- Allow more values in the 'type' attribute, eg file, block, blktap:aio,
blktap:qcow, etc. This feels wrong because the blktap:* entries are
really still 'file' types.
- Introduce a new attribute 'driver' where you can specify 'loop',
'blktap:aio', 'blktap:qcow', etc
- Introduce a new element 'driver' where you can specify the same
<disk type="file">
<driver type='blktap:aio'/>
</disk>
- Same as above, but normalize the driver type further
<disk type="file">
<driver type='blktap' backend='aio' />
</disk>
My preference is probably option 3 or 4.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
18 years, 1 month
