[Libvir] PATCH: Fix virtual neworks with xm driver
by Daniel P. Berrange
The virtual networks stuff was never added to the xm driver for Xen 3.0.3
or earlier. This means that if adding a virtual network the bridge device
won't get defined in the config. This patch addreses this, and also fixes
a tiny mem leak in the equivalent code in the xend driver.
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 -=|
16 years, 9 months
[Libvir] PATCH: Improve performance on Xen
by Daniel P. Berrange
The Xen implementations of
virDomainLookupByID
virDomainLookupByUUID
virDomainLookupByName
virDomainGetOSType
all have sub-optimal performance since they speak to XenD. The lookupXXX
functions all basically require 3 pieces of info in the end (name,id,uuid).
They each get given one piece & have to lookup the other piece.
Every running domain has to have an entry in XenStore on /local/domain/N
where 'N' is the id. Under this location there is always a 'name' field.
So if we have the id we can efficiently get the name. I just realized that
the getdomaininfo hypercall struct contains the uuid and id. So for the
ByID and ByUUID calls we can get all the info we need with a hypercall and
a read of xenstore. This is very efficient compared to hitting XenD.
As of Xen 3.1.0 hypervisor the flags in the getdomaininfo hypercall struct
also mark whether the guest is HVM vs paraivrt, so we can also implement
the GetOSType api with a single hypercall.
That just leaves the ByName impl. The only way I can think of doing this
is to scan /local/domain/N in xenstore until we find it. I'm going to try
this, but I'm not convinced it'll be any significantly than talking to XenD.
I may be surprised though.
Any for the 3 improvements I have done, the 'virsh dominfo' call has improved
when using either ID or UUID:
Create a set of UUIDs & IDs
# for i in `seq 1 500` ; do echo dominfo 73 ; done > ids.txt
# for i in `seq 1 500` ; do echo dominfo 8f07fe28-753f-2729-d76d-bdbd892f949a ; done > uuids.txt
Now before measurements:
# time ./virsh < ids.txt > /dev/null
real 0m17.317s
user 0m0.144s
sys 0m0.164s
# time ./virsh < uuids.txt > /dev/null
real 0m14.432s
user 0m0.236s
sys 0m0.460s
Against the after measurements:
# time ./virsh < demo.txt > /dev/null
real 0m0.259s
user 0m0.100s
sys 0m0.072s
# time ./virsh < demo.txt > /dev/null
real 0m0.482s
user 0m0.324s
sys 0m0.108s
A pretty good speedup really considering how frequently these calls are
made if you're monitoring domains frequently.
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 -=|
16 years, 9 months
[Libvir] Proposal: Block device and network stats
by Richard W.M. Jones
With the very timely question that has been raised about block and
network device stats, I'm posting my proposed interface. I almost have
this working for the Xen case on my test machine.
The idea of this interface is to be optimised for the following case:
* stats need to be fetched frequently (eg. once per second)
* the layout of devices doesn't change often (ie. adding or removing
devices from domains is very infrequent)
* most domains have only a single block and single network device
With the above assumptions, the idea is that you would use the API like
this:
(1) When the program starts up or (infrequently) is notified of a change
or when a new domain appears, the program calls virDomainGetXMLDesc and
parses out the //domain/devices/interface and //domain/devices/disk
fields to get the list of network interfaces and block devices.
So for each domain, you'll have two lists like this:
dom[1]["blockdevs"] = ["xvda"]
dom[1]["interfaces"] = ["virbr0"]
(2) Frequently (eg. once per second) the program calls (in the above case):
virDomainBlockStats (dom1, "xvda", &bstats, sizeof bstats);
virDomainInterfaceStats (dom1, "virbr0", &istats, sizeof istats);
(3) Since stats are cumulative the program must do its own subtraction
and calculation in order to display throughput per second.
The implementation goes directly from the name "xvda" to the backend
device (/sys/devices/xen-backend/-
[type]-[domid]-[major:minor]/statistics) for block devices, and slightly
more complicatedly to a particular line in /proc/net/dev for network
interfaces. (Note in the Xen case, the name "virbr0" is little more
than a placeholder to mean "the zeroth interface for domain d"). In
particular the current implementation doesn't cache anything.
This should all work fine in the Linux / Xen case. libxenstat gives us
sample code that we can copy for the Solaris / Xen case, but it would
need testing from someone with access to such a machine. I don't think
qemu supports stats at all. Initially we won't support stats for tap
devices because there needs to be an upstream patch to support this
(http://lists.xensource.com/archives/html/xen-changelog/2007-02/msg00278.html).
The extra size parameter will allow us to extend the stats structures in
future, maintaining binary backwards compatibility with existing clients.
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
16 years, 9 months
[Libvir] Xen physical host statistics
by Mindaugas Kiznis
Hello,
- I am trying to make an application, which would connect to a remote
xen host and fetch some information about total (physical) CPU usage,
total memory usage, network and disk I/O. I have managed to do a remote
statistics grabber for CPU and memory usage using libvirt. I couldn't
find any source of information about libvirt ability to return I/O
numbers. Also haven't found any other solution yet. Any suggestions?
Thank you in advance!
Best regards,
Mindaugas Kiznis
16 years, 9 months
[Libvir] PATCH: UUID code cleanup
by Daniel P. Berrange
Browsing the source I noticed we have many differents constants for UUID
length, many ways of turning a UUID into a string, 2 ways of turning a
string into a UUID (one with some scary signed <-> unsigned casting).
This is just a result of the way the code evolved & I figured it could do
with cleaning up a little.
So I added a virUUIDFormat(const unsigned char uuid, char *uuidstr) method
to the uuid.c, removed all the other equivalent code throughout and kiled
all the duplicate constants. So now everything UUID related is in the one
place uuid.c, while the constants are in libvirt/libvirt.h
Its a surprisingly big patch, but it should not have any functional change
with one exception. The XenD driver used to generate XML <uuid>...</uuid>
tags without any '-' embedded in them. All other places use the '-' and
technically the RFC requires them. Our parser is flexible enough to cope
with, or without '-'.
diffstat ~/libvirt-uuid-cleanup.patch
proxy/Makefile.am | 2 -
qemud/internal.h | 2 -
src/libvirt.c | 34 +++-------------------------
src/openvz_conf.c | 14 +++++------
src/openvz_conf.h | 3 --
src/qemu_conf.c | 20 ++++++----------
src/qemu_conf.h | 5 +---
src/test.c | 18 +++++----------
src/uuid.c | 57 +++++++++++++++++++++++++++++++++--------------
src/uuid.h | 13 ++++------
src/xend_internal.c | 62 +++++++++++++++++++---------------------------------
src/xm_internal.c | 31 +++++---------------------
src/xml.c | 61 ---------------------------------------------------
src/xml.h | 1
14 files changed, 104 insertions(+), 219 deletions(-)
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 -=|
16 years, 9 months
[Libvir] ANNOUNCE: Virt-top - a top-like utility for displaying virtualization stats
by Richard W.M. Jones
I'm pleased to announce the first release of virt-top, which is a
top-like utility for displaying virtualization stats.
It aims to look and feel very much like regular 'top', so as to be as
familiar as possible for systems administrators. You can also use it as
a pleasant replacement for xentop.
It uses libvirt, so can display stats across a variety of different
hypervisors and virtualization systems (not just Xen, although that is
where the testing has gone so far).
http://et.redhat.com/~rjones/virt-top/
The license is a combination of LGPL (for the library) and GPL (for the
virt-top program).
Current status
--------------
You can view domains and use familiar keys like 'P'/'M'/... to sort by
processor/memory/..., and 'd'/'s' to set the delay between updates.
Also some common top command-line options are implemented. The man page
is here: http://et.redhat.com/~rjones/virt-top/virt-top.txt
There are a variety of source and binary RPMs available for Fedora
users. I don't yet have a working Debian/Ubuntu package, but will have
a go at making one tomorrow.
The next thing I'll be working on is showing virtual and physical CPU
usage of guests. After that I'm hoping to discuss extensions to libvirt
to make other interesting statistics available to virt-top, in
particular disk and network I/O stats.
There are a few data collection artifacts which need to be investigated.
In particular, %CPU sometimes goes over 100%. Obviously accurate data
collection is an important goal for this tool.
Memory usage is good: typical 'RES' (in regular top) for virt-top is
just under 2.5 MB, and I've had it running for hours at a time without
memory usage increasing, which seems to indicate that there aren't any
major memory leaks.
Development
-----------
The program is currently very small: exactly 500 lines of code!
If you want to dive in and send me patches they are most welcome, but
remember that I'm trying to make this utility act as much like 'top' as
possible, so if 'top' does it in a particular way, then I'd prefer
virt-top to do the same thing. (May not apply to obscure top
functionality, if top does something silly).
If you're a systems administrator, not a programmer, and you'd like
virt-top to have some particular feature, then please let me know, and I
will be happy to review it and code it for you.
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
16 years, 9 months
[Libvir] libvirt daemon UNIX socket auth with PolicyKit
by Daniel P. Berrange
Currently our authentication model for local connections is using the basic
UNIX file permissions, possibly with a setuid helper (in Xen case only). It
can be summarized as
- If app using libvirt is running as root
=> full access
- Else
=> read only access
The latter is enforced by fact that in Xen case libvirt_proxy only has impl
for a handful of read only APIs, or in non-Xen case that the UNIX domain
socket for the daemon /var/run/libvirt/libvirt-sock is mode 0700, while
/var/run/libvirt/libvirt-sock-ro is 0777 & the daemon enforces based on which
socket the client connects to.
This is good because it allows non-root to at least monitor guest state
while requiring root authentication for actually changing state.
This is bad because it requires any app which wants to change state to run
as root. ie we are required to launch virt-manager as root to gain ability
to manage local guests. Problem with this include:
- running the entire PyGTK & GTK & X codebase as root is undesirable
- no integration with the DBus desktop session (gnome-vfs integartion)
- no integration with the GNOME keyring (for VNC server passwords)
- redundant (&dangerous) if all you want to do is manage remote libvirt hosts
In summary what I really need for virt-manager is
- Always run as non-root
- Authenticate for local guest management (ie read+write)
UNIX domain sockets already provide a way for each end to identify the PID
and UID of the other end. This enables the libvirt daemon to determine the
identity of the application on the other end. With this information the
daemon merely needs to check this identity against some access control policy
rules. Where to get/define these rules though ?
Enter PolicyKit.
http://lists.freedesktop.org/archives/hal/2006-March/004770.html
http://lists.freedesktop.org/archives/hal/2007-June/008815.html
PolicyKit is a freedesktop.org project to replace all the distro specific
'do admin stuff as root' hacks like consolehelper[1], sudo, gksudo with
a standard mechanism. Most importantly this mechanism does not require
that the application in question run as root, or ever gain root privileges.
In addition this is completely configurable by the administrator in a
application independant manner.
How would the daemon use PolicyKit for authenticating clients on UNIX
domain sockets
- libvirtd defines two actions it can check called 'libvirt-local-monitor
(read only monitoring of state), and 'libvirt-local-manage' (full
read-write management).
- Both libvirt-sock and libvirt-sock-ro are mode 0777 (ie all users)
- A connection arrives on the UNIX domain socket either libvirt-sock-ro
or libvirt-sock
- libvirtd use SO_PEERCRED to get the PID of the client
- If the connection is on libvirt-sock-ro 'action' is 'libvirt-local-monitor'
Else if connection is on libvirt-sock 'action' is 'libvirt-local-manage'
- Libvirt asks policy kit if PID is allowed to perform the 'action'
-> Yes, connection proceeds
-> No, connection is dropped
NB, having two separate UNIX domain sockets is strictly speaking redundant
now - the daemon could simply check each 'action' in turn - but keeping the
separate sockets simplifies the code, because it minimises the diffs when
PolicyKit is not enabled by the 'configure' script.
How is policy determined by PolicyKit ?
- libvirt RPM provides /usr/share/PolicyKit/policy/libvirt.policy
- This file defines the two actions it supports 'libvirt-local-monitor'
and 'libvirt-local-manage'.
- For each action we define a default policy for an active desktop
session, and an inactive desktop session. The sample policy is to
allow 'libvirt-local-monitor' for any local desktop session, but
only allow 'libvirt-local-manage' for the active session with the
additional requirement that the user authenticate with PolicyKit
using the root password.
This basically replicates the existing security semantics, without requiring
that we run virt-manager itself as root. This accomplishes the core goal.
There are other benefits to PolicyKit though - the administrator can override
the application provided default Policy. For example, could add a rule that
says
"if the user fred is logged into the local X session, allow them to do
'libvirt-local-manage' without any further prompts for root password"
Since PolicyKit is a general framework, that rule could be generalized
beyond just virt-manager
"if the user fred is logged into the local X session, allow them to do
any defined action without any further prompts for root password"
Or going the other way the administrator can lock things down requiring a
root password even for read only monitoring of VMs. Or a halfway house of
requiring the user's own password (sudo equiv, instead of su equiva).
If course this doesn't just apply to virt-manager either. This transparently
'just works' for virsh too & any other apps using libvirt - eg if policy
grants 'libvirt-local-manage' then you can do full management whether virsh
is root or not.
This all talks about enforcement of policy from the daemon side. There is
one outstanding question - if the policy so requires, where/how do we ask
the user to enter their credentials.
PolicyKit provides two mechanisms for this:
- A command line tool polkit-grant which uses pam to authenticate you
as root, or using your own user password. If successful you will have
been granted the permission to perform that action for the remainder
of the session.
- A DBus service for triggering display of some UI for authenticating.
There is a GNOME impl of this service & likely a KDE impl too.
eg with virsh start off without any priveleges
$ virsh --connect qemu:///system net-list
libvir: Remote error : Connection reset by peer
error: failed to connect to the hypervisor
error: no valid connection
$ polkit-grant --action libvirtd-local-manage2
Authentication is required.
Password:
Keep this privilege for the session? [no/session]?
$ ./src/virsh --connect qemu:///system net-list --all
Name State Autostart
-----------------------------------------
default active yes
One option is to have the libvirt library spawn polkit-grant if not finding
any $DISPLAY, and call the DBus service (for UI prompt) if finding any. The
other option is to punt this code upto the application - eg virt-manager
always call the DBus service, while virsh always call polkit-grant.
Finally, PolicyKit is new in Fedora 8 if you wish to try this out. The
configure script is setup so that it automagically detects presence of
PolicyKit and only turns it on at compile time if its available. The
fallback is to continue current behaviour of restricting based on the
socket permissions.
http://fedoraproject.org/wiki/Releases/FeaturePolicyKit
Finally, finally, if we enable PolicyKit support, then we should disable
the Xen specific libvirt_proxy setuid binary, since it would subvert the
policy for libvirt-local-monitor. IMHO we should just kill the setuid
binary altogether, since we already require that the libvirt daemon be
running for the networking APIs & this provides read-only access already
which works for non-Xen drivers too.
Attaching the patch implementing the proof of concept
$ diffstat ~/libvirt-policykit.patch
configure.in | 60 ++++++++++++++++++--
qemud/Makefile.am | 12 +++-
qemud/internal.h | 23 ++++++-
qemud/libvirtd.policy | 41 ++++++++++++++
qemud/qemud.c | 145 ++++++++++++++++++++++++++++++++++++++++++++------
qemud/remote.c | 6 +-
6 files changed, 258 insertions(+), 29 deletions(-)
Oh, finally, finally, finally. PolicyKit is pretty new so I'd understand
if there's some resistance to including it in an official libvirt release
at this point. I think the patch is small enough that we could carry it
as add-on in the Fedora RPMs only to start with untill its proved to be
maintainable long term - I really need this for Fedora 8 to make virt-manager
work sanely - ie not need to run as root.
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 -=|
16 years, 9 months
[Libvir] [PATCH] A variety of fixes for Debian, old versions of GnuTLS
by Richard W.M. Jones
Attached is a patch to get libvirt working on Debian/stable again.
(1) Add ./configure option --disable-stack-protector. The stack
protector feature is still enabled by default, but it causes no end of
problems when compiling on Debian systems, apparently because of bugs in
their gcc. So Debian users would be well advised to try disabling it if
they have problems building.
(2) Adds support for GnuTLS 1.0.x by detecting this version and enabling
some simple compatibility macros.
(3) In qemudDispatchClientEvent, a prototype shadowed a global function
name. A simple name change to a parameter fixes it.
(4) Debian (and likely non-Linux systems also) don't have the
SIOCBRADDBR and related ioctls. If these are missing, then I've changed
this to runtime errors. This means that these systems won't be able to
start the network daemon, but other (non-network) features of libvirt
continue to work.
(5) Removed a warning in src/qemu_conf.c.
Rich.
PS. You need to drop the file gnutls_1_0_compat.h into src/
subdirectory. Sorry this file isn't in the proper patch but I don't
have write access to CVS from the testing machine.
--
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
16 years, 9 months
[Libvir] [PATCH] Fix libvirtd --config / -f option
by Richard W.M. Jones
As well as fixing the --config/-f option for libvirtd, this also changes
an abort() into a meaningful error message.
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
16 years, 9 months
[Libvir] ANNOUNCE: OCaml bindings 0.3.1.0 released
by Richard W.M. Jones
http://et.redhat.com/~rjones/ocaml-libvirt/
This removes use of the dangerous vir{Domain,Network}GetConnect
functions and makes the relationship between domains, networks and
connections explicit to the garbage collector.
I've also added support for domain migration.
mlvirtmanager displays the hostname when connected to multiple remote
hosts (see screenshot attached).
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
16 years, 9 months
