[libvirt] A laundry list of "TODO" items for libvirt
by Daniel P. Berrange
A bunch of us at Red Hat had a bit of a brainstorming session to make a
list of things we'd like to see added to libvirt going forward, to better
support our needs for virtualization in Fedora / oVirt. We've put details
of everything up on the libvirt wiki:
http://wiki.libvirt.org/page/Todo
This list isn't a firm commitment to actually implement these features.
We may later decide that some of them don't belong in libvirt (eg, the
question of allowing multiu-thread access to virConnectPtr is open to
debate). Nor have we got people actually working on these items - unless
explicitly noted against a todo item. If anyone is looking to do work
on libvirt and isn't sure of what to work on, this list may be of interest.
Also, this is a wiki, so feel free to add more ideas - or add expanded
details to existing ideas. Or reply to this mail, and one of us will
add new ideas to the wiki for you
The only request is that you don't actually start implementing things from
the list without first discussing proposals on this list, because most of
these ideas need more design / analysis before its reasonable to write
code
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 8 months
[libvirt] XML representation of security labels
by James Morris
As part of the sVirt effort, I'm investigating how and when to label
the resources accessed by domains.
There is already some support for querying security labels in libvirt,
although it does not seem to be widely used as yet.
For storage pool XML descriptors, there's a permissions element per
http://libvirt.org/formatstorage.html :
<permissions>
<owner>0744</owner>
<group>0744</group>
<mode>0744</mode>
<label>virt_image_t</label>
</permissions>
The label element in this is currently assumed by libvirt to be an SELinux
security label obtainable via getfilecon(3).
There are a couple of issues here:
1. We should probably not build security model specific code directly into
the library. It's more flexible and also cleaner to abstract the security
model out. So, I suggest making a plugin scheme similar to those already
present in libvirt, where a security model can register a driver to handle
abstracted operations like "getSecurityLabel".
2. The XML format for security labels needs to be extended to indicate
which security model is in use, and potentially carry model-specific
metadata. For SELinux, we may want to know what type of policy is active,
and later, be able to interpret labels generated on other systems.
In this case, I suggest we deprecate the existing label element and, if
present, assume it's a plain SELinux context (or perhaps ignore it).
I'd suggest we implement a new label element to avoid breaking
compatibility and to avoid potential confusion with other types of device
labels (e.g. as you might see via /dev/disk/by-label).
So, how about the following:
<seclabel>
<model>
<!-- model-specific elements in here, to be handled by
named security driver, in this case "selinux" -->
<selinux>
<type>targeted</type>
</selinux>
</model>
<value>system_u:object_r:virt_image_t:s0</value>
</seclabel>
The model and value elements would be mandatory, but possibly empty.
The seclabel element would be a child of the permissions element:
<permissions>
<owner>0744</owner>
<group>0744</group>
<mode>0744</mode>
<seclabel>
<model>
<selinux>
<type>targeted</type>
</selinux>
</model>
<value>system_u:object_r:virt_image_t:s0</value>
</seclabel>
</permissions>
It would also likely be reused for labeling domains themselves, and other
resources.
Thoughts?
- James
--
James Morris
<jmorris(a)namei.org>
15 years, 8 months
[libvirt] [PATCH] virConnectListAllDomains
by Richard W.M. Jones
As observed in this thread:
https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html
several tools need to grab the complete list of domains frequently
(eg. virt-manager and virt-top) and the way they do it currently is
very inefficient, both in terms of the number of round-trips in the
remote case (4 + 2*N calls), and the fact that we could implement
drivers better if we could get all domains in a single operation.
Therefore this patch adds the virConnectListAllDomains call:
int virConnectListAllDomains (virConnectPtr conn,
virDomainPtr **domains,
virDomainInfo **infos,
int stateflags);
This call gets domains and virDomainInfo structures. The reasons for
getting the info structures as well are that we get them anyway as a
side-effect of filtering on state, and virsh, virt-top and
virt-manager all get the info structures at the same time as getting
the domains.
As in Dan's proposal above, you can filter on state, with three
special values (VIR_DOMAIN_LIST_ACTIVE, VIR_DOMAIN_LIST_INACTIVE and
VIR_DOMAIN_LIST_ALL) which do what you think.
virConnectListAllDomains is always available. If the driver doesn't
implement it directly, then we emulate it in src/libvirt.c. This
ensures that virt-manager etc can start to use this call straightaway.
There is no direct implementation for Xen or QEMU yet. (If the
general patch is accepted, then I'll implement at least for QEMU).
However there is already a benefit to applying this patch because it
optimizes the remote case from 4 + 2*N calls down to 1.
There is no Python binding yet.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 64 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
15 years, 8 months
[libvirt] "Choose alarm timer" feature for kvm
by Tiziano Müller
Hi everyone
In KVM it is possible to select the alarm timer being used (dynticks,
hpet, rtc, unix).
Is someone already working on the support of this for libvirt?
If not I'll see that I can come up with patches for libvirt and virt-inst within the next month (if time permits).
Cheers,
Tiziano
--
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail : dev-zero(a)gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
15 years, 8 months
[libvirt] [PATCH]: Allow libvirt to manage bridges "plugged into" physical devices
by Chris Lalancette
All,
For ovirt, we need the ability to have a bridge configured that is "plugged
in" to an external interface; that is, the physical interface is one of the
interfaces on the bridge. This allows us to manage physical hardware outside
this box, since the ovirt WUI appliance will be hooked to this same bridge and
will send/receive traffic to these external machines. Currently we are doing
this "by hand" with scripts, which is clearly sub-optimal.
This relatively simple patch adds a new "forward" type called "bridge"
(yes, it's a bad name; I'm open to suggestions). Basically, when you have a
bridge with this forward type, we take the "dev" that is specified (say, eth1),
plug it into the bridge, and add the appropriate iptables rule to bridge traffic.
With this in place, we can get rid of our hacky scripts and let libvirt do
the dirty work for us. I also imagine this could be useful to support
"xen-style" bridges, without necessarily using the Xen networking scripts.
Comments?
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
15 years, 8 months
[libvirt] Problems using libvirt (linking errors)
by Johannes Formann
Hello,
I habe a problem using a recent libvirt-Version (0.4.4) (installed from
backports.org) in my own programms.
I had used an older Version a while ago, but I think something might
have changed in the API(?), since the old code has the same problems
now.
I include the headers
#include <libvirt/libvirt.h>
#include <libvirt/virterror.h>
but when linking, I'll get errors like
XSSserver.o: In function `XSSserver::XSSserverinitializeService(void*)':
/root/rsplib-2.5.0/rsplib/XSSserver.cc:68: undefined reference to
`virInitialize'
/root/rsplib-2.5.0/rsplib/XSSserver.cc:72: undefined reference to
`virConnectOpen'
here is the function:
bool XSSserver::XSSserverinitializeService(void* userData)
{
if ( virInitialize() != 0) {
puts("WARNING: vir Initializew failed\n") ;
return false;
}
virCon=virConnectOpen(NULL);
if (virCon != NULL ) {
return true;
}
puts("WARNING: Initialisierung misslungen") ;
return false;
}
Any hints what I've done wrong/how to debug that problem?
regards Johannes
15 years, 8 months
[libvirt] PATCH: Fix fetch of NUMA info when building Xen capabilities
by Daniel P. Berrange
Currently if you use libvirt CVS HEAD on Xen >= 3.2 hypervisor it will fail
to open a connection. This is because I mistakenly removed the passing of
the virConnectPtr object when querying NUMA capabilities from XenD. This
patch fixes that regression
Daniel
Index: src/xen_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/xen_internal.c,v
retrieving revision 1.124
diff -u -p -r1.124 xen_internal.c
--- src/xen_internal.c 20 Aug 2008 20:48:36 -0000 1.124
+++ src/xen_internal.c 28 Aug 2008 15:38:05 -0000
@@ -2159,7 +2159,8 @@ struct guest_arch {
static virCapsPtr
-xenHypervisorBuildCapabilities(const char *hostmachine,
+xenHypervisorBuildCapabilities(virConnectPtr conn,
+ const char *hostmachine,
int host_pae,
char *hvm_type,
struct guest_arch *guest_archs,
@@ -2185,7 +2186,7 @@ xenHypervisorBuildCapabilities(const cha
if (sys_interface_version >= 4) {
- if (xenDaemonNodeGetTopology(NULL, caps) != 0) {
+ if (xenDaemonNodeGetTopology(conn, caps) != 0) {
virCapabilitiesFree(caps);
return NULL;
}
@@ -2271,7 +2272,8 @@ xenHypervisorBuildCapabilities(const cha
* Return the capabilities of this hypervisor.
*/
virCapsPtr
-xenHypervisorMakeCapabilitiesInternal(const char *hostmachine,
+xenHypervisorMakeCapabilitiesInternal(virConnectPtr conn,
+ const char *hostmachine,
FILE *cpuinfo, FILE *capabilities)
{
char line[1024], *str, *token;
@@ -2404,7 +2406,8 @@ xenHypervisorMakeCapabilitiesInternal(co
}
}
- if ((caps = xenHypervisorBuildCapabilities(hostmachine,
+ if ((caps = xenHypervisorBuildCapabilities(conn,
+ hostmachine,
host_pae,
hvm_type,
guest_archs,
@@ -2425,7 +2428,7 @@ xenHypervisorMakeCapabilitiesInternal(co
* Return the capabilities of this hypervisor.
*/
virCapsPtr
-xenHypervisorMakeCapabilities(void)
+xenHypervisorMakeCapabilities(virConnectPtr conn)
{
virCapsPtr caps;
FILE *cpuinfo, *capabilities;
@@ -2451,7 +2454,10 @@ xenHypervisorMakeCapabilities(void)
}
}
- caps = xenHypervisorMakeCapabilitiesInternal(utsname.machine, cpuinfo, capabilities);
+ caps = xenHypervisorMakeCapabilitiesInternal(conn,
+ utsname.machine,
+ cpuinfo,
+ capabilities);
if (cpuinfo)
fclose(cpuinfo);
Index: src/xen_internal.h
===================================================================
RCS file: /data/cvs/libvirt/src/xen_internal.h,v
retrieving revision 1.29
diff -u -p -r1.29 xen_internal.h
--- src/xen_internal.h 20 Aug 2008 20:48:36 -0000 1.29
+++ src/xen_internal.h 28 Aug 2008 15:38:05 -0000
@@ -17,7 +17,7 @@
extern struct xenUnifiedDriver xenHypervisorDriver;
int xenHypervisorInit (void);
-virCapsPtr xenHypervisorMakeCapabilities (void);
+virCapsPtr xenHypervisorMakeCapabilities (virConnectPtr conn);
/* The following calls are made directly by the Xen proxy: */
@@ -38,7 +38,8 @@ int xenHypervisorClose (virConnectPtr c
int xenHypervisorGetVersion (virConnectPtr conn,
unsigned long *hvVer);
virCapsPtr
- xenHypervisorMakeCapabilitiesInternal(const char *hostmachine,
+ xenHypervisorMakeCapabilitiesInternal(virConnectPtr conn,
+ const char *hostmachine,
FILE *cpuinfo,
FILE *capabilities);
char *
Index: src/xen_unified.c
===================================================================
RCS file: /data/cvs/libvirt/src/xen_unified.c,v
retrieving revision 1.53
diff -u -p -r1.53 xen_unified.c
--- src/xen_unified.c 20 Aug 2008 20:48:36 -0000 1.53
+++ src/xen_unified.c 28 Aug 2008 15:38:05 -0000
@@ -333,7 +333,7 @@ xenUnifiedOpen (virConnectPtr conn, xmlU
}
}
- if (!(priv->caps = xenHypervisorMakeCapabilities())) {
+ if (!(priv->caps = xenHypervisorMakeCapabilities(conn))) {
DEBUG0("Failed to make capabilities");
goto fail;
}
Index: tests/xencapstest.c
===================================================================
RCS file: /data/cvs/libvirt/tests/xencapstest.c,v
retrieving revision 1.14
diff -u -p -r1.14 xencapstest.c
--- tests/xencapstest.c 25 Jul 2008 13:17:27 -0000 1.14
+++ tests/xencapstest.c 28 Aug 2008 15:38:05 -0000
@@ -49,7 +49,7 @@ static int testCompareFiles(const char *
if (!(fp2 = fopen(capabilities, "r")))
goto fail;
- if (!(caps = xenHypervisorMakeCapabilitiesInternal(hostmachine, fp1, fp2)))
+ if (!(caps = xenHypervisorMakeCapabilitiesInternal(NULL, hostmachine, fp1, fp2)))
goto fail;
if (!(actualxml = virCapabilitiesFormatXML(caps)))
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 8 months
[libvirt] Need Info on virNodeGetCellsFreeMemory
by ajishrao
Hi,
how to find the memory utilization of the whole which is running
with some guest? By libvirt I can only see virNodeGetCellsFreeMemory
relevant API, But didn't understand how to use it.
Thanks & Regards
--Ajish
15 years, 8 months
Re: [libvirt] Error compiling libvirt 0.4.4
by Richard W.M. Jones
On Thu, Aug 28, 2008 at 11:25:44AM -0300, Everton P. Alexandre wrote:
> I managed to do the installation!!! But now, when I
> try to use the virsh or to execute a program, the
> following message appear:
>
> libvir: Remote error : No such file or directory
> libvir: warning : Failed to find the network: Is the
> daemon running?
So as the message says, you need to run the daemon (libvirtd). Well,
truthfully you don't _need_ to run it, unless you want certain
features like remote access, managed networks or QEMU support.
If you've got libvirtd running but you still get that message,
then it'll probably be either a security or a paths problem.
http://libvirt.org/remote.html
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 64 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
15 years, 8 months
