[Libvir] virsh - vcpuinfo cmd not working in 0.2.2
by Jan Michael
Cheers libvirt,
I've tested the CLI virsh with my recent compiled version of libvirt
and version 0.1.9. In Version 0.2.2 vcpuinfo provides wrong
information. In version 0.1.9 only the values for VCPU and CPU are
wrong. Do you have any idea why?
See the test results below.
Jan
> xm vcpu-list
Name ID VCPUs CPU State Time(s) CPU
Affinity
Domain-0 0 0 0 r-- 95463.9 any cpu
Domain-0 0 1 - --p 55.6 any cpu
stornode 6 0 1 -b- 2036.1 1
worknode 5 0 1 -b- 2073.9 1
> virsh vcpuinfo (0,5,6) in version 0.2.2
- Domain-0
VCPU: 0
CPU: 0
State: blocked
CPU time: 0.0s
CPU Affinity: --
- worknode
virsh # vcpuinfo 5
VCPU: 0
CPU: 0
State: blocked
CPU time: 4.3s
CPU Affinity: --
- stornode
VCPU: 0
CPU: 0
State: blocked
CPU time: 4.3s
CPU Affinity: --
> virsh vcpuinfo (0,5,6) in version 0.1.9
- Domain-0
VCPU: 0
CPU: 0
State: running
CPU time: 95466.7s
CPU Affinity: yy
- worknode
VCPU: 0
CPU: 1
State: blocked
CPU time: 2074.2s
CPU Affinity: -y
- stornode
VCPU: 0
CPU: 1
State: blocked
CPU time: 2036.5s
CPU Affinity: -y
17 years
[Libvir] How libvirt handles QEMU?
by Jun Koi
Hello,
I am new to libvirt, so have a question. My concern is: libvirt can
manage QEMU VMs. The point is thatI QEMU doesnt not export monitor
interface to outside (at least that is what I know about older version
of QEMU, not sure if anything changed recently).
So how can libvirt does something like: pause, resume or extract
internal information about a QEMU VM?
Thank you,
Jun
17 years
[Libvir] [PATCH] Remote 0/8: Plan
by Richard W.M. Jones
Below is the plan for delivering the remote patch for review in stages.
More details about in each email. I only expect to get through the
first two emails today.
Rich.
1 Additional error handling
---------------------------
M include/libvirt/virterror.h
M src/virterror.c
2 Client-server protocol
------------------------
A qemud/remote_protocol.x
A qemud/rpcgen_fix.pl
A qemud/remote_protocol.c
A qemud/remote_protocol.h
3 Client-side
-------------
A src/remote_internal.c
A src/remote_internal.h
M src/driver.h
M src/libvirt.c
4 Server-side call dispatch
---------------------------
A qemud/remote.c
A qemud/remote_generate_stubs.pl
A qemud/remote_dispatch_localvars.h
A qemud/remote_dispatch_proc_switch.h
A qemud/remote_dispatch_prototypes.h
5 Client-side QEMUD modifications
---------------------------------
M src/qemu_internal.c
6 Server-side QEMUD modifications
---------------------------------
A qemud/protocol.x
A qemud/protocol.c
M qemud/protocol.h
M qemud/Makefile.am
M qemud/conf.c
M qemud/dispatch.c
M qemud/dispatch.h
M qemud/internal.h
M qemud/qemud.c
M qemud/uuid.c
7 Documentation updates
-----------------------
M docs/libvir.html
M docs/remote.html
8 Build system
--------------
M .cvsignore
M configure.in
A libvirtd.conf
M src/Makefile.am
A RENAMES
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years
[Libvir] gl_COMPILER_FLAGS gives an error
by Richard W.M. Jones
./configure: line 21215: syntax error near unexpected token `-fprofile-arcs'
./configure: line 21215: ` gl_COMPILER_FLAGS(-fprofile-arcs)'
The only solution I can seem to find is to comment out the calls to
gl_COMPILER_FLAGS in configure.in. Can't very much on Google about what
gl_COMPILER_FLAGS is supposed to do.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
17 years
[Libvir] [PATCH] Three cleanup patches
by Richard W.M. Jones
* Add some extra generated files to .cvsignore
* Remove an unused header in qemud/uuid.c
* Log an error if xenHypervisorOpen fails because xenHypervisorInit has
failed.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years
[Libvir] Making QEMU use the real internal driver API
by Daniel P. Berrange
So currently, as we all know, the QEMU driver is just a shim through to the
QEMU daemon. Looking at the code for Rich's remote driver I quite like the
way the remote driver / server works like, and don't like the ugliness of
having the special case QEMU code in there. We always had a long term plan
to try & make the QEMU driver fit into the regular driver API more cleanly
but not really tackled it yet. Similarly we've periodically brought up the
idea of having asynchronous notifications of 'interesting' state changes
in the drivers, to eliminate the need for polling.
After a little thinking I have an idea that may let us address both issues
in one go. Or to be more precise, put infrastructure in place to let us
move closer to allowing async notiifcations.
First let me consider the files under qemud/ ....
Self-contained helper routines, ignore for rest of discussion
bridge.c
bridge.h
iptables.c
iptables.h
uuid.c
uuid.h
buf.c
buf.h
The on the wire protcol definition, this is the bit we want to kill in favour
of the generic remote wire protocol:
protocol.h
The code to convert from wire -> function calls. Again this ought to die in
favour of the generic remote dispatcher.
dispatch.c
dispatch.h
The QEMU config handling routines.
conf.c
conf.h
The impl of core APIs:
driver.c
driver.h
Finally the 'server':
internal.h
qemud.c
The end-goal is that 'qemud/driver.c' would become 'src/qemu_internal.c'
implementing the official internal driver API. The 'qemud/conf.c' would
likely become 'src/qemu_config.c'.
The key difference between the internal driver API, and the QEMU specific
driver 'API' inside the daemon is the prescense of some global state via
the 'qemud_server' struct. If we can figure out a way to store this state
inside the regular driver API we can refactor that without much problem.
Then there is the need for an event loop for monitoring the file handles
of the QEMU processes, which at the moment is fairly tied into the event
loop used to monitor the client/server socket handles. This existing code
is rather ugly & has bad structure IMHO. The result is that code which
ought to be isolated in driver.c, is instead part of qemud.c because of
event loop integration.
Finally, there is some code which runs on startup, and shutdown of the
daemon, to do stuff like auto-start of VMs / networks, and clean shutdown
of the same.
Oh, and we need to make sure the QEMU driver is never activated locally,
only when libvirt.so is being used as part of 'libvirtd'.
So at a high level what I think we'd need to add to the internal driver
API to make this possible is
In driver.h:
typedef int (*virDrvStartup)(void);
typedef int (*virDrvShutdown)(void);
Adding these to the 'virDriver' struct. Regular apps using libvirt.so
would never trigger these APIs - they're only intended for the daemon,
so I figure we'd have to private APIs in the libivrt.so (but not in
the libvirt.h)
__virStartup(void);
__virShutdown(void);
Since these are only called by the daemon, we now conveniently also have
a way to stop the QEMU driver being locally activated.
Next up, event loops. First, we don't want to mandate a particular impl
of an event loop. If you get into the argument about QT vs GLib vs libevent
and libvirt picks one, then you make it hard for libvirt to integrate with
apps using the other. Second, we don't want to assume that 1 connection
== 1 file handle. We also don't want to assume that the number of file
handles used by a driver stays the same over time. Basically we need to
expect that any single driver connection will have zero or more file
handles that it is interested in.
The DBus library deals with this exact same issue & the solution is very
simple. The app using the libvirt registers a callback which the internal
driver than then use to (un)register file handles.
So in src/internal.h we'd add methods for internal drivers to call to
add / remove file handles to/from the event loop:
/*
* @fd: the file handle on which the event occurred
* @event: bitset of one or more of POLLxxx constants from poll.h
* @opaque: data associated with 'fd'
*
* Return 0 to continue monitoring, -1 if an error occurred
* and the handle should no longer be monitored
*/
typedef int (*virEventCallback)(int fd, int events, void *opaque);
/*
* @fd: the file handle to start monitoring
* @events: bitset of POLLxxx contants to monitor
* @cb: callback to invoke when an event ocurrs
* @opaque: data to pass into callback's opaque parameter
*/
int virEventAddHandle(int fd, int events, virEventCallback cb, void *opaque);
/*
* @fd: the file handle to stop monitoring
*/
int virEventRemoveHandle(int fd);
And we'd also add methods for a user of libvirt to register an event loop
implementation:
typedef int (*virEventAddHandleImpl)(int fd, int events, opaque);
typedef int (*virEventRemoveHandleImpl)(int fd);
void virEventInitialize(virEventAddHandleImpl add, virEventRemoveHandleImpl remove);
If we want to add support for async events into the public API, then the
virEventInitialize method could instead be in libvirt.h, and exported in
the libvirt.so. Otherwise we could mark it private __virEventInitialize
in libvirt.so.
That I think should be enough to let us move QEMU into a regular style libvirt
driver.
NB, what follows now is a quick brain-dump - I'm not suggesting implementing
this yet - its really a rough idea of general architecture. We'd definitely
want to prototype it in a test app before committing to something like this.
There's also many many scenarios to be thought about beyond just watching
create/destroy events
Thinking about a public API we could have:
enum {
VIR_CONN_DOMAIN_CREATED,
VIR_CONN_DOMAIN_DESTROYED;
} virConnectEvent;
typedef int (*virConnectNotifyCallback)(virConnectPtr dom, unsigned char uuid[16], int event);
virConnectNotify(virConnectPtr conn, virConnectNofifyCallback cb);
An application using this would thus be able to do something like
/* Assume there's a convenient libvirtglib.so addon providing these for apps */
extern virEventAddHandleImpl virGLibEventAddHandle;
extern virEventRemoveHandleImpl virGLibEventRemoveHandle;
int domainWatcher(virConnectPtr dom, unsigned char uuid[16], int event) {
... do something ...
}
int main () {
virConnectPtr con;
con = virConnectOpen(NULL);
/* Setup an event loop via glib */
virEventInitilize(virGLibEventAddHandle, virGLibEventRemoveHandle);
virConnectNotify(conn, domainWatcher);
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 -=|
17 years
[Libvir] [PATCH] Fields in virDomainPtr which appear to be never used
by Richard W.M. Jones
Below is the definition of struct _virDomain from internal.h. I may be
missing something big (well, it wouldn't be the first time), but as far
as I can see some of these fields are never used, and some are set but
can never be read.
struct _virDomain {
unsigned int magic; /* specific value to check */
OK
int uses; /* reference count */
OK
virConnectPtr conn; /* pointer back to the connection */
OK
char *name; /* the domain external name */
OK
char *path; /* the domain internal path */
This field is set in src/xs_internal.c, but nowhere in libvirt does it
appear to be read. The only other time it is reference is in hash.c
where it is freed if non-NULL.
int id; /* the domain ID */
OK
int flags; /* extra flags */
Apparently this field could be set to DOMAIN_IS_SHUTDOWN or
DOMAIN_IS_DEFINED. However neither of these symbols are used, and
moreover this structure field looks like it is never written or read.
unsigned char uuid[VIR_UUID_BUFLEN]; /* the domain unique identifier */
OK
char *xml; /* the XML description for defined domains */
This field is, as far as I can tell, never set anywhere. However the
code in hash.c does check whether it is set and will free it upon
destruction of the _virDomain object.
};
With this analysis in mind, attached is a patch which removes these
three fields (path, flags, xml) and the unused virDomainFlags, with no
apparent ill-effects.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years
[Libvir] [PATCH] Fix the value of XEN_V2_OP_GETDOMAININFOLIST
by Saori Fukuta
Hi,
The value of "Max memory" shown by using "virsh dominfo" is different from xm
command.
# virsh dominfo HVM_RH5_sda6 | grep mem
Max memory: 300000 kB
Used memory: 264064 kB
# xm li -l HVM_RH5_sda6 | grep mem
(maxmem 450)
(memory 292)
(shadow_memory 5)
So, I changed the definition as follows,
(before)
#define XEN_V2_OP_GETDOMAININFOLIST 6
(changed)
#define XEN_V2_OP_GETDOMAININFOLIST 5
and I could get the value that I want.
# ./virsh dominfo HVM_RH5_sda6 | grep mem
Max memory: 460800 kB
Used memory: 299008 kB
# xm li -l HVM_RH5_sda6 | grep mem
(maxmem 450)
(memory 292)
(shadow_memory 5)
I think that is not mistake because the XEN_V2_OP_GETDOMAININFOLIST is a
system operation, so the definition is not exactly wrong.
/usr/include/xen/sysctl.h:#define XEN_SYSCTL_getdomaininfolist 6
Do you know any reason for this?
Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com>
Thanks,
Saori Fukuta.
Index: xen_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/xen_internal.c,v
retrieving revision 1.71
diff -u -p -r1.71 xen_internal.c
--- xen_internal.c 13 Apr 2007 00:43:57 -0000 1.71
+++ xen_internal.c 26 Apr 2007 11:41:03 -0000
@@ -117,7 +117,7 @@ static regex_t xen_cap_rec;
#define XEN_V0_OP_GETDOMAININFOLIST 38
#define XEN_V1_OP_GETDOMAININFOLIST 38
-#define XEN_V2_OP_GETDOMAININFOLIST 6
+#define XEN_V2_OP_GETDOMAININFOLIST 5
struct xen_v0_getdomaininfo {
domid_t domain; /* the domain number */
17 years
