- Devel - libvirt List Archives

Re: [libvirt] RFC [3/3]: Lock manager usage scenarios
by Ayal Baron 20 Sep '10

20 Sep '10

----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > On Tue, Sep 14, 2010 at 05:03:21PM -0400, Ayal Baron wrote: > > > > ----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > > > > > > > That is probably possible with the current security driver > > > implementations > > > but more generally I think it will still hit some trouble. > > > Specifically > > > one of the items on our todo list is a new security driver that > makes > > > use > > > of Linux container namespace functionality to isolate the VMs, so > they > > > > > > can't even see other resources / processes on the host. This may > well > > > prevent the sync manager wrapper talking to a central sync mnager > > > process > > > The general rule we aim for is that once libvirtd has spawned a > VM > > > they > > > are completely isolated with exception of any disks marked with > > > <shareable/> > > > In other words, any communictions channels must be > > > initiated/established > > > by the mgmt layer to the VM process, with nothing to be > established in > > > the > > > reverse direction. > > Correct me if I'm wrong, but the security limitations (selinux > context) > > would only take effect after the "exec", no? so the process could > still > > communicate with the daemon, open an FD and then exec. After exec, > the > > VM would be locked down but the daemon could still wait on the FD to > see > > whether VM has died. > > It depends on which exec you are talking about here. If the comms to > the daemon are done straight from the libvirtd plugin, then it would > still be unrestricted. If the comms were done from the supervisor > process, it would be restricted. > > Daniel I'm talking about the supervisor. You said you spoke to Dan Walsh and that the supervisor and qemu processes could get different contexts. Now you're saying the supervisor would be restricted nonetheless. What am I missing? > -- > |: 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 :|

4 5

[libvirt] [PATCH 0/3] Experimental support for DTrace probes
by Daniel P. Berrange 17 Sep '10

17 Sep '10

This patchset provides the infrastructure for supporting dynamic probing of libvirtd, using static DTrace markers. This can be used by SystemTAP on Linux, or DTrace on Solaris/OS-X/BSD for low overhead tracing. The proof of concept provides a handful of markers wrt to network client connections, security & auth. Obviously it can be expanded to cover a huge area of our codebase for different tasks. The hard bit is deciding what should be exposed as a probe point. Ideally probes should not be changed/removed once added, since this would break any user tracing scripts. So a little care needs to be taken in placing probes to be robust against future code re-factoring. Daniel

2 5

[libvirt] Front page of wiki reorganised
by Justin Clift 17 Sep '10

17 Sep '10

Hi us, Just reorganised the front page of the wiki, pulling in links from some of the other pages, and ordering things by categories: http://wiki.libvirt.org/page/Main_Page It's now a longer page, more like a central jump point. Feedback/flames/etc, welcome. :) Regards and best wishes, Justin Clift

2 1

[libvirt] [PATCH 0/2] tests: silence qemuargv2xmltest
by Eric Blake 16 Sep '10

16 Sep '10

Oh well, this missed the 0.8.4 deadline. This cleanup has already been mentioned for some time on the list, and I finally got it done. Eric Blake (2): tests: clean up qemuargv2xmltest tests: silence qemuargv2xmltest noise tests/qemuargv2xmltest.c | 200 +++++++++++++++++++++++++++------------------- 1 files changed, 117 insertions(+), 83 deletions(-) -- 1.7.2.2

3 9

[libvirt] [PATCH] docs: reworked the policykit patch submitted by Patrick Dignan
by Justin Clift 16 Sep '10

16 Sep '10

Tweaked the PolicyKit documentation improvement patch submitted by Patrick Dignan. Additionally, removed the reference to PolicyKit.conf, which is no longer used by PolicyKit, plus added a link to the expanded PolicyKit example page on the wiki. --- The concept submitted was both valid and useful, but the keyswords in the "Result*" lines are case sensitive, so the example provided didn't work. docs/auth.html.in | 42 ++++++++++++++++++++---------------------- 1 files changed, 20 insertions(+), 22 deletions(-) diff --git a/docs/auth.html.in b/docs/auth.html.in index ab6c3e9..13731eb 100644 --- a/docs/auth.html.in +++ b/docs/auth.html.in @@ -65,29 +65,27 @@ auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket. </p> <p> -The default policy can be overridden by the administrator using the PolicyKit -master configuration file in <code>/etc/PolicyKit/PolicyKit.conf</code>. The -<code>PolicyKit.conf(5)</code> manual page provides details on the syntax -available. The two libvirt daemon actions available are named <code>org.libvirt.unix.monitor</code> -for the RO socket, and <code>org.libvirt.unix.manage</code> for the RW socket. -</p> +The default policy can be overridden by creating a new policy file in the +local override directory <code>/etc/polkit-1/localauthority/50-local.d/</code>. +Policy files should have a unique name ending with .pkla. Using reverse DNS +naming works well. Information on the options available can be found by +reading the pklocalauthority man page. The two libvirt daemon actions +available are named <code>org.libvirt.unix.manage</code> for full management +access, and <code>org.libvirt.unix.monitor</code> for read-only access. + </p> <p> -As an example, to allow a user <code>fred</code> full access to the RW socket, -while requiring <code>joe</code> to authenticate with the admin password, -would require adding the following snippet to <code>PolicyKit.conf</code>. -</p> - <pre> - <match action="org.libvirt.unix.manage"> - <match user="fred"> - <return result="yes"/> - </match> - </match> - <match action="org.libvirt.unix.manage"> - <match user="joe"> - <return result="auth_admin"/> - </match> - </match> -</pre> +As an example, this gives the user <code>fred</code> full management access: + </p> +<pre>[Allow fred libvirt management permissions] +Identity=unix-user:fred +Action=org.libvirt.unix.manage +ResultAny=yes +ResultInactive=yes +ResultActive=yes</pre> + <p> +Further examples of PolicyKit setup can be found on the +<a href="http://wiki.libvirt.org/page/SSHPolicyKitSetup">wiki page</a>. + </p> <h3><a name="ACL_server_username">Username/password auth</a></h3> <p> The plain TCP socket of the libvirt daemon defaults to using SASL for authentication. -- 1.7.2.3

2 2

[libvirt] [PATCH] docs: fix the xml validity errors regarding name and id
by Justin Clift 16 Sep '10

16 Sep '10

Got sick of seeing the "validity error : ID Objects already defined" errors, which this patch addresses. --- docs/api.html.in | 8 ++++---- docs/architecture.html.in | 6 +++--- docs/downloads.html.in | 2 +- docs/remote.html.in | 30 +++++++++++++++--------------- docs/storage.html.in | 16 ++++++++-------- docs/uri.html.in | 24 ++++++++++++------------ 6 files changed, 43 insertions(+), 43 deletions(-) diff --git a/docs/api.html.in b/docs/api.html.in index 4b6a529..c9c0c67 100644 --- a/docs/api.html.in +++ b/docs/api.html.in @@ -19,7 +19,7 @@ <a href="#Remote">Daemon and remote access</a> </li> </ul> - <h2><a name="Objects" id="Objects">Objects exposed</a></h2> + <h2><a name="Objects" id="id-Objects">Objects exposed</a></h2> <p> As defined in the <a href="goals.html">goals section</a>, libvirt API need to expose all the resources needed to manage the virtualization support of recent operating systems. The first object manipulated though @@ -85,7 +85,7 @@ set of nodes.</li> </ul> - <h2><a name="Functions" id="Functions">Functions and naming + <h2><a name="Functions" id="id-Functions">Functions and naming conventions</a></h2> <p> The naming of the functions present in the library is usually made of a prefix describing the object associated to the function @@ -120,13 +120,13 @@ </ul> <p> For more in-depth details of the storage related APIs see <a href="storage.html">the storage management page</a>, - <h2><a name="Driver" id="Driver">The libvirt drivers</a></h2> + <h2><a name="Driver" id="id-Driver">The libvirt drivers</a></h2> <p></p> <p class="image"> <img alt="The libvirt driver architecture" src="libvirt-driver-arch.png"/> </p> - <h2><a name="Remote" id="Remote">Daemon and remote access</a></h2> + <h2><a name="Remote" id="id-Remote">Daemon and remote access</a></h2> <p></p> <p class="image"> <img alt="The libvirt daemon and remote architecture" diff --git a/docs/architecture.html.in b/docs/architecture.html.in index f5cc520..c147435 100644 --- a/docs/architecture.html.in +++ b/docs/architecture.html.in @@ -16,7 +16,7 @@ engines:</p> </li> </ul> <h3> - <a name="Xen" id="Xen">Libvirt Xen support</a> + <a name="Xen" id="id-Xen">Libvirt Xen support</a> </h3> <p>When running in a Xen environment, programs using libvirt have to execute in "Domain 0", which is the primary Linux OS loaded on the machine. That OS @@ -49,7 +49,7 @@ connect to initialize the library. It will then fork a libvirt_proxy program running as root and providing read_only access to the API, this is then only useful for reporting and monitoring.</p> <h3> - <a name="QEmu" id="QEmu">Libvirt QEmu and KVM support</a> + <a name="QEmu" id="id-QEmu">Libvirt QEmu and KVM support</a> </h3> <p>The model for QEmu and KVM is completely similar, basically KVM is based on QEmu for the process controlling a new domain, only small details differs @@ -63,7 +63,7 @@ domain, by specifying the architecture and machine type targeted.</p> <p>The code controlling the QEmu process is available in the <code>qemud/</code> directory.</p> <h3> - <a name="drivers" id="drivers">the driver based architecture</a> + <a name="drivers" id="id-drivers">the driver based architecture</a> </h3> <p>As the previous section explains, libvirt can communicate using different channels with the current hypervisor, and should also be able to use diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 2ce1048..3bea264 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -91,7 +91,7 @@ <h1>libvirt Installation</h1> - <h2><a name="Compilatio" id="Compilatio">Compilation</a></h2> + <h2><a name="Compilatio" id="id-Compilatio">Compilation</a></h2> <p> libvirt uses the standard configure/make/install steps: diff --git a/docs/remote.html.in b/docs/remote.html.in index b8b8f2b..eb787c2 100644 --- a/docs/remote.html.in +++ b/docs/remote.html.in @@ -58,7 +58,7 @@ machines through authenticated and encrypted connections. </li> </ul> <h3> - <a name="Remote_basic_usage" id="Remote_basic_usage">Basic usage</a> + <a name="Remote_basic_usage" id="id-Remote_basic_usage">Basic usage</a> </h3> <p> On the remote machine, <code>libvirtd</code> should be running. @@ -92,7 +92,7 @@ relating to failures in the remote transport itself. </li> much slower than, say, direct hypervisor calls. </li> </ul> <h3> - <a name="Remote_transports" id="Remote_transports">Transports</a> + <a name="Remote_transports" id="id-Remote_transports">Transports</a> </h3> <p> Remote libvirt supports a range of transports: @@ -140,7 +140,7 @@ Remote libvirt supports a range of transports: The default transport, if no other is specified, is <code>tls</code>. </p> <h3> - <a name="Remote_URI_reference" id="Remote_URI_reference">Remote URIs</a> + <a name="Remote_URI_reference" id="id-Remote_URI_reference">Remote URIs</a> </h3> <p> See also: <a href="uri.html">documentation on ordinary ("local") URIs</a>. @@ -181,7 +181,7 @@ settings. </li> </ul> <h4> - <a name="Remote_URI_parameters" id="Remote_URI_parameters">Extra parameters</a> + <a name="Remote_URI_parameters" id="id-Remote_URI_parameters">Extra parameters</a> </h4> <p> Extra parameters can be added to remote URIs as part @@ -304,10 +304,10 @@ Note that parameter values must be </tr> </table> <h3> - <a name="Remote_certificates" id="Remote_certificates">Generating TLS certificates</a> + <a name="Remote_certificates" id="id-Remote_certificates">Generating TLS certificates</a> </h3> <h4> - <a name="Remote_PKI" id="Remote_PKI">Public Key Infrastructure set up</a> + <a name="Remote_PKI" id="id-Remote_PKI">Public Key Infrastructure set up</a> </h4> <p> If you are unsure how to create TLS certificates, skip to the @@ -367,7 +367,7 @@ next section. </tr> </table> <h4> - <a name="Remote_TLS_background" id="Remote_TLS_background">Background to TLS certificates</a> + <a name="Remote_TLS_background" id="id-Remote_TLS_background">Background to TLS certificates</a> </h4> <p> Libvirt supports TLS certificates for verifying the identity @@ -402,7 +402,7 @@ address. You may want to change this to make it less (or more) permissive, depending on your needs. </p> <h4> - <a name="Remote_TLS_CA" id="Remote_TLS_CA">Setting up a Certificate Authority (CA)</a> + <a name="Remote_TLS_CA" id="id-Remote_TLS_CA">Setting up a Certificate Authority (CA)</a> </h4> <p> You will need the <a href="http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html">GnuTLS @@ -473,7 +473,7 @@ key carefully as you will need it when you come to issue certificates for your clients and servers. </p> <h4> - <a name="Remote_TLS_server_certificates" id="Remote_TLS_server_certificates">Issuing server certificates</a> + <a name="Remote_TLS_server_certificates" id="id-Remote_TLS_server_certificates">Issuing server certificates</a> </h4> <p> For each server (libvirtd) you need to issue a certificate @@ -556,7 +556,7 @@ which can be installed on the server as </li> </ul> <h4> - <a name="Remote_TLS_client_certificates" id="Remote_TLS_client_certificates">Issuing client certificates</a> + <a name="Remote_TLS_client_certificates" id="id-Remote_TLS_client_certificates">Issuing client certificates</a> </h4> <p> For each client (ie. any program linked with libvirt, such as @@ -609,7 +609,7 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem </li> </ol> <h4> - <a name="Remote_TLS_troubleshooting" id="Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a> + <a name="Remote_TLS_troubleshooting" id="id-Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a> </h4> <dl> <dt> failed to verify client's certificate </dt> @@ -627,7 +627,7 @@ to analyze the setup on the client or server machines, preferably as root. It will try to point out the possible problems and provide solutions to fix the set up up to a point where you have secure remote access.</p> <h3> - <a name="Remote_libvirtd_configuration" id="Remote_libvirtd_configuration">libvirtd configuration file</a> + <a name="Remote_libvirtd_configuration" id="id-Remote_libvirtd_configuration">libvirtd configuration file</a> </h3> <p> Libvirtd (the remote daemon) is configured from a file called @@ -795,7 +795,7 @@ Blank lines and comments beginning with <code>#</code> are ignored. </tr> </table> <h3> - <a name="Remote_IPv6" id="Remote_IPv6">IPv6 support</a> + <a name="Remote_IPv6" id="id-Remote_IPv6">IPv6 support</a> </h3> <p> The libvirtd service and libvirt remote client driver both use the @@ -808,7 +808,7 @@ connection will be made, otherwise IPv4 will be used. In summary it should just 'do the right thing(tm)'. </p> <h3> - <a name="Remote_limitations" id="Remote_limitations">Limitations</a> + <a name="Remote_limitations" id="id-Remote_limitations">Limitations</a> </h3> <ul> <li> Fine-grained authentication: libvirt in general, @@ -821,7 +821,7 @@ just read-write/read-only as at present. Please come and discuss these issues and more on <a href="https://www.redhat.com/mailman/listinfo/libvir-list" title="libvir-list mailing list">the mailing list</a>. </p> <h3> - <a name="Remote_implementation_notes" id="Remote_implementation_notes">Implementation notes</a> + <a name="Remote_implementation_notes" id="id-Remote_implementation_notes">Implementation notes</a> </h3> <p> The current implementation uses <a href="http://en.wikipedia.org/wiki/External_Data_Representation" title="External Data Representation">XDR</a>-encoded packets with a diff --git a/docs/storage.html.in b/docs/storage.html.in index 079192b..a1eddf8 100644 --- a/docs/storage.html.in +++ b/docs/storage.html.in @@ -33,7 +33,7 @@ libvirt. </li> </ul> - <h2><a name="StorageBackendDir" id="StorageBackendDir">Directory pool</a></h2> + <h2><a name="StorageBackendDir" id="id-StorageBackendDir">Directory pool</a></h2> <p> A pool with a type of <code>dir</code> provides the means to manage files within a directory. The files can be fully allocated raw files, @@ -85,7 +85,7 @@ libvirt. </p> - <h2><a name="StorageBackendFS" id="StorageBackendFS">Filesystem pool</a></h2> + <h2><a name="StorageBackendFS" id="id-StorageBackendFS">Filesystem pool</a></h2> <p> This is a variant of the directory pool. Instead of creating a directory on an existing mounted filesystem though, it expects @@ -156,7 +156,7 @@ libvirt. </p> - <h2><a name="StorageBackendNetFS" id="StorageBackendNetFS">Network filesystem pool</a></h2> + <h2><a name="StorageBackendNetFS" id="id-StorageBackendNetFS">Network filesystem pool</a></h2> <p> This is a variant of the filesystem pool. Instead of requiring a local block device as the source, it requires the name of a @@ -196,7 +196,7 @@ libvirt. </p> - <h2><a name="StorageBackendLogical" id="StorageBackendLogical">Logical volume pools</a></h2> + <h2><a name="StorageBackendLogical" id="id-StorageBackendLogical">Logical volume pools</a></h2> <p> This provides a pool based on an LVM volume group. For a pre-defined LVM volume group, simply providing the group @@ -231,7 +231,7 @@ libvirt. </p> - <h2><a name="StorageBackendDisk" id="StorageBackendDisk">Disk volume pools</a></h2> + <h2><a name="StorageBackendDisk" id="id-StorageBackendDisk">Disk volume pools</a></h2> <p> This provides a pool based on a physical disk. Volumes are created by adding partitions to the disk. Disk pools are have constraints @@ -318,7 +318,7 @@ libvirt. </ul> - <h2><a name="StorageBackendISCSI" id="StorageBackendISCSI">iSCSI volume pools</a></h2> + <h2><a name="StorageBackendISCSI" id="id-StorageBackendISCSI">iSCSI volume pools</a></h2> <p> This provides a pool based on an iSCSI target. Volumes must be pre-allocated on the iSCSI server, and cannot be created via @@ -351,7 +351,7 @@ libvirt. The iSCSI volume pool does not use the volume format type element. </p> - <h2><a name="StorageBackendSCSI" id="StorageBackendSCSI">SCSI volume pools</a></h2> + <h2><a name="StorageBackendSCSI" id="id-StorageBackendSCSI">SCSI volume pools</a></h2> <p> This provides a pool based on a SCSI HBA. Volumes are preexisting SCSI LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX names @@ -383,7 +383,7 @@ libvirt. The SCSI volume pool does not use the volume format type element. </p> - <h2><a name="StorageBackendMultipath" id="StorageBackendMultipath">Multipath pools</a></h2> + <h2><a name="StorageBackendMultipath" id="id-StorageBackendMultipath">Multipath pools</a></h2> <p> This provides a pool that contains all the multipath devices on the host. Volume creating is not supported via the libvirt APIs. diff --git a/docs/uri.html.in b/docs/uri.html.in index 0540dab..ffb86c1 100644 --- a/docs/uri.html.in +++ b/docs/uri.html.in @@ -37,7 +37,7 @@ documents libvirt URIs. </li> </ul> <h3> - <a name="URI_libvirt" id="URI_libvirt">Specifying URIs to libvirt</a> + <a name="URI_libvirt" id="id-URI_libvirt">Specifying URIs to libvirt</a> </h3> <p> The URI is passed as the <code>name</code> parameter to <a href="html/libvirt-libvirt.html#virConnectOpen"><code>virConnectOpen</code></a> or <a href="html/libvirt-libvirt.html#virConnectOpenReadOnly"><code>virConnectOpenReadOnly</code></a>. For example: @@ -46,7 +46,7 @@ The URI is passed as the <code>name</code> parameter to <a href="html/libvirt-li virConnectPtr conn = virConnectOpenReadOnly (<b>"test:///default"</b>); </pre> <h3> - <a name="URI_virsh" id="URI_virsh">Specifying URIs to virsh, virt-manager and virt-install</a> + <a name="URI_virsh" id="id-URI_virsh">Specifying URIs to virsh, virt-manager and virt-install</a> </h3> <p> In virsh use the <code>-c</code> or <code>--connect</code> option: @@ -77,7 +77,7 @@ In virt-install use the <code>--connect=</code><i>URI</i> option: virt-install <b>--connect=test:///default</b> <i>[other options]</i> </pre> <h3> - <a name="URI_xen" id="URI_xen">xen:/// URI</a> + <a name="URI_xen" id="id-URI_xen">xen:/// URI</a> </h3> <p> <i>This section describes a feature which is new in libvirt > @@ -88,7 +88,7 @@ To access a Xen hypervisor running on the local machine use the URI <code>xen:///</code>. </p> <h3> - <a name="URI_qemu" id="URI_qemu">qemu:///... QEMU and KVM URIs</a> + <a name="URI_qemu" id="id-URI_qemu">qemu:///... QEMU and KVM URIs</a> </h3> <p> To use QEMU support in libvirt you must be running the @@ -120,7 +120,7 @@ KVM guests in the <a href="format.html#KVM1">guest XML as described here</a>. </p> <h3> - <a name="URI_remote" id="URI_remote">Remote URIs</a> + <a name="URI_remote" id="id-URI_remote">Remote URIs</a> </h3> <p> Remote URIs are formed by taking ordinary local URIs and adding a @@ -183,7 +183,7 @@ remote URI reference</a> and <a href="remote.html">full documentation for libvirt remote support</a>. </p> <h3> - <a name="URI_test" id="URI_test">test:///... Test URIs</a> + <a name="URI_test" id="id-URI_test">test:///... Test URIs</a> </h3> <p> The test driver is a dummy hypervisor for test purposes. @@ -197,10 +197,10 @@ a set of host definitions held in the named file. </li> </ul> <h3> - <a name="URI_legacy" id="URI_legacy">Other & legacy URI formats</a> + <a name="URI_legacy" id="id-URI_legacy">Other & legacy URI formats</a> </h3> <h4> - <a name="URI_NULL" id="URI_NULL">NULL and empty string URIs</a> + <a name="URI_NULL" id="id-URI_NULL">NULL and empty string URIs</a> </h4> <p> Libvirt allows you to pass a <code>NULL</code> pointer to @@ -224,7 +224,7 @@ application wishes to connect specifically to a Xen hypervisor, then for future proofing it should choose a full <a href="#URI_xen"><code>xen:///</code> URI</a>. </p> <h4> - <a name="URI_file" id="URI_file">File paths (xend-unix-server)</a> + <a name="URI_file" id="id-URI_file">File paths (xend-unix-server)</a> </h4> <p> If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>: @@ -241,7 +241,7 @@ using a file URI such as: virsh -c ///var/run/xend/xend-socket </pre> <h4> - <a name="URI_http" id="URI_http">Legacy: <code>http://...</code> (xend-http-server)</a> + <a name="URI_http" id="id-URI_http">Legacy: <code>http://...</code> (xend-http-server)</a> </h4> <p> If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>: @@ -277,7 +277,7 @@ Notes: documentation as "unix server" or "http server".</li> </ol> <h4> - <a name="URI_legacy_xen" id="URI_legacy_xen">Legacy: <code>"xen"</code></a> + <a name="URI_legacy_xen" id="id-URI_legacy_xen">Legacy: <code>"xen"</code></a> </h4> <p> Another legacy URI is to specify name as the string @@ -285,7 +285,7 @@ Another legacy URI is to specify name as the string hypervisor. However you should prefer a full <a href="#URI_xen"><code>xen:///</code> URI</a> in all future code. </p> <h4> - <a name="URI_legacy_proxy" id="URI_legacy_proxy">Legacy: Xen proxy</a> + <a name="URI_legacy_proxy" id="id-URI_legacy_proxy">Legacy: Xen proxy</a> </h4> <p> Libvirt continues to support connections to a separately running Xen -- 1.7.2.3

3 4

Re: [libvirt] Why is avahi-daemon being started?
by Eric Blake 16 Sep '10

16 Sep '10

[adding libvir-list] On 09/07/2010 07:42 AM, Tom Horsley wrote: > On Tue, 07 Sep 2010 13:51:09 +0100 > Adam Williamson wrote: > >>> I did find a "Should-start: avahi-daemon" comment in the libvirtd >>> init script, so maybe that is the source. >> >> Shouldn't be. 'Should-start' means 'if this other service is enabled, it >> should be started before this one': it's not a strict dependency, 'this >> other service MUST be started before this one'. > > Yea, changing the comment there didn't fix anything, but it was a good > hint since I finally found the "mdns_adv" setting in the libvirtd.conf > file and uncommenting it did finally squash avahi-daemon :-). I'm wondering if this means that libvirt should change any of its policies about auto-starting avahi-daemon, or at the very least, if there is a documentation shortcoming on why libvirt defaults to enabling this and when you might want to change that default. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 6

Re: [libvirt] IPv6 structs on MacOS X
by Justin Clift 15 Sep '10

15 Sep '10

On 09/16/2010 04:52 AM, Bruno Haible wrote: <snip> > This message talks about the unportability of a field 's6_addr32' in > 'struct in6_addr'. Sure this is unportable: POSIX [1] specifies only the > presence of 's6_addr'. > > I don't see why gnulib should support this: An application can perfectly > access the 16 bytes of the s6_addr[] array. Why would it need to access a > specific part of it in a special way? My apologies. I should have been significantly clearer in what I was trying for there. :) (adding the libvirt devel mailing list back in, due to relevance) Tried compiling libvirt on OS X, which errored on this piece of IPv6 code: http://www.redhat.com/archives/libvir-list/2010-September/msg00243.html The message I quoted to Eric above, which you've then looked at, was danpb wondering whether we should be using gnulib to avoid the portability problem. This stuff is outside my area of expertise though. :) Regards and best wishes, Justin Clift

2 5

Re: [libvirt] OSX 10.6 build failures
by Osier 15 Sep '10

15 Sep '10

----- "Justin Clift" <jclift(a)redhat.com> wrote: > From: "Justin Clift" <jclift(a)redhat.com> > To: "Libvirt Developers Mailing List" <libvir-list(a)redhat.com> > Sent: Wednesday, September 15, 2010 7:42:48 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi > Subject: [libvirt] OSX 10.6 build failures > > Hi us, > > Going through the process of getting libvirt to compile on OSX, making > > notes of the failures on the way through (from a clean system) to be > fixed. > > a) libtool -> glibtool > libtoolize -> glibtoolize > > It turns out that autogen.sh is hard coded to use "libtool", and > wants the GNU version. > > OSX supplies has it's own version, without a --version option, so > autogen.sh fails. > > Installing GNU libtool through MacPorts, makes it available as > glibtool, with libtoolize being glibtoolize. > > Adjusting autogen.sh to detect that, then set LIBTOOL and > LIBTOOLIZE > appropriately was fairly trivial. > > Will submit a patch to fix that in a bit. > > > b) pkg-config > > The next thing to barf was autoconf, complaining about > AC_MSG_ERROR > not being a defined macro. > > Googling with some persistence showed this is caused by > pkg-config > not being installed. Fixed that. > > Will submit a patch for that too. Probably "pkg-config > --version" > based, copying the approach used for the other autogen.sh checks. > > > c) This is a compilation failure, one I don't readily know how to > fix: > > ... > Making all in src > make all-am > CC libvirt_util_la-network.lo > util/network.c: In function 'getIPv6Addr': > util/network.c:50: error: 'struct in6_addr' has no member named > 's6_addr16' > util/network.c:50: error: 'struct in6_addr' has no member named > 's6_addr16' > util/network.c:50: error: 'struct in6_addr' has no member named > 's6_addr16' > util/network.c:50: error: 'struct in6_addr' has no member named > 's6_addr16' > make[3]: *** [libvirt_util_la-network.lo] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > $ > > They're the only problems so far, though most things have been > disabled > on the ./configure line so it's only the client libraries being > built. > > Anyone know how to address that third one? > % man ipv6 Address Format struct sockaddr_in6 { sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* port number */ uint32_t sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* Scope ID (new in 2.4) */ }; struct in6_addr { unsigned char s6_addr[16]; /* IPv6 address */ }; % vim libvirt/src/util/network.c 43 static int getIPv6Addr(virSocketAddrPtr addr, virIPv6AddrPtr tab) { 44 int i; 45 46 if ((addr == NULL) || (tab == NULL) || (addr->stor.ss_family != AF_INET6 )) 47 return(-1); 48 49 for (i = 0;i < 8;i++) { 50 (*tab)[i] = ntohs(addr->inet6.sin6_addr.s6_addr16[i]); 51 } 52 53 return(0); 54 } I guess it's a typo, should be "addr->inet6.sin6_addr.s6_addr[i]", but not "addr->inet6.sin6_addr.s6_addr16[i]".. :-) - Osier > Regards and best wishes, > > Justin Clift > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list

4 4

[libvirt] [PATCH] virsh: change wexitstatus order to allow compilation on mac osx
by Justin Clift 15 Sep '10

15 Sep '10

This is the simple fix Daniel Veillard suggested last year: http://www.redhat.com/archives/libvir-list/2009-May/msg00459.html --- tools/virsh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 57ea618..c148f7b 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -8646,7 +8646,7 @@ editFile (vshControl *ctl, const char *filename) VIR_FREE(command); return -1; } - if (command_ret != WEXITSTATUS (0)) { + if (WEXITSTATUS(command_ret) != 0) { vshError(ctl, _("%s: command exited with non-zero status"), command); VIR_FREE(command); -- 1.7.2.2

2 3

Re: [libvirt] [PATCH] autogen.sh: added glibtool and pkg-config checks
by Bruce Korb 15 Sep '10

15 Sep '10

Please don't use my project name when talking about bootstrap process. "autogen.sh" has become a popular misnomer, so at least keep the ".sh" suffix. Thanks. On Wed, Sep 15, 2010 at 10:02 AM, Eric Blake <eblake(a)redhat.com> wrote: > [adding bug-gnulib] > > On 09/15/2010 06:36 AM, Justin Clift wrote: >> >> OSX MacPorts has libtool named as glibtool, with libtoolize >> named as glibtoolize. This patch adds support for this, and also >> adds a check for pkg-config, to warn when it is missing. > > Hmm - would it be easier to make bootstrap.conf list pkg-config as a > prerequisite, rather than having to hack up autogen.sh to do that? > > Also, if I'm reading the code right, changing bootstrap.conf to list > 'libtoolize' instead of 'libtool' as the prerequisite will let you get by > with overriding just $LIBTOOLIZE instead of both $LIBTOOL and $LIBTOOLIZE. > > Additionally it may be sufficient to just teach upstream > gnulib/build-aux/bootstrap to use 'find_tool LIBTOOLIZE libtoolize > glibtoolize', at which point re-syncing to upstream bootstrap will > automatically pick up on the right libtool for MacOS without you having to > hack libvirt's autogen.sh in the first place :) > > So, NACK to this version of the libvirt patch, and instead let me do some > gnulib work... Not to mention that Gary is working on some upstream patches > to improve bootstrap modularity, and there is also a request to add > 'bootstrap --skip-git' that I need to respond to... > > -- > Eric Blake eblake(a)redhat.com +1-801-349-2682 > Libvirt virtualization library http://libvirt.org > >

1 0

[libvirt] [PATCH] libvirtd: improve the error message displayed on tls client auth failure
by Justin Clift 15 Sep '10

15 Sep '10

This address BZ # 556599: https://bugzilla.redhat.com/show_bug.cgi?id=556599 --- daemon/libvirtd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c index 711360b..46e22bd 100644 --- a/daemon/libvirtd.c +++ b/daemon/libvirtd.c @@ -1226,7 +1226,7 @@ remoteCheckCertificate (gnutls_session_t session) if (i == 0) { if (!remoteCheckDN (cert)) { /* This is the most common error: make it informative. */ - VIR_ERROR0(_("remoteCheckCertificate: client's Distinguished Name is not on the list of allowed clients (tls_allowed_dn_list). Use 'openssl x509 -in clientcert.pem -text' to view the Distinguished Name field in the client certificate, or run this daemon with --verbose option.")); + VIR_ERROR0(_("remoteCheckCertificate: client's Distinguished Name is not on the list of allowed clients (tls_allowed_dn_list). Use 'certtool -i --infile clientcert.pem' to view the Distinguished Name field in the client certificate, or run this daemon with --verbose option.")); gnutls_x509_crt_deinit (cert); return -1; } -- 1.7.2.2

3 6

[libvirt] [PATCH] maint: silence warning from libtool
by Eric Blake 14 Sep '10

14 Sep '10

I got tired of seeing this: config.status: executing libtool commands /bin/rm: cannot remove `libtoolT': No such file or directory config.status: executing po-directories commands While I was at it, there were a couple other unused variables. * configure.ac (RM, MV, TAR): Drop; nothing in libvirt directly uses this, and assigning RM interferes with libtool. --- configure.ac | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index a71f5e8..5ded22b 100644 --- a/configure.ac +++ b/configure.ac @@ -122,9 +122,6 @@ AM_CONDITIONAL([HAVE_GLIBC_RPCGEN], $ac_cv_path_RPCGEN -t </dev/null >/dev/null 2>&1]) dnl Miscellaneous external programs. -AC_PATH_PROG([RM], [rm], [/bin/rm]) -AC_PATH_PROG([MV], [mv], [/bin/mv]) -AC_PATH_PROG([TAR], [tar], [/bin/tar]) AC_PATH_PROG([XMLLINT], [xmllint], [/usr/bin/xmllint]) AC_PATH_PROG([XMLCATALOG], [xmlcatalog], [/usr/bin/xmlcatalog]) AC_PATH_PROG([XSLTPROC], [xsltproc], [/usr/bin/xsltproc]) -- 1.7.2.2

2 2

[libvirt] New wiki pages with libvirt SSH setup instructions
by Justin Clift 14 Sep '10

14 Sep '10

Hi all, Just added some new pages to the wiki, this time covering how to configure remote access to libvirt through SSH, not using root: http://wiki.libvirt.org/page/SSHSetup <--- entry page http://wiki.libvirt.org/page/SSHPolicyKitSetup This has details for several different Linux distributions: * RHEL 5 & 6 * Fedora 11-13 * Centos 5 & 6 * Ubuntu 10.04 Server & Desktop * openSUSE 11.2 onwards Does anyone have info they'd like to include for other distributions? :) Regards and best wishes, Justin Clift

1 0

[libvirt] [PATCH] Rebuild network filter for UML guests on updates
by Soren Hansen 14 Sep '10

14 Sep '10

When nwfilter support was added to UML, I didn't realise the UML driver needed instrumentation to make updating nwfilters on the fly work. This patch adds this bit of glue. Signed-off-by: Soren Hansen <soren(a)linux2go.dk> --- src/uml/uml_driver.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/src/uml/uml_driver.c b/src/uml/uml_driver.c index 40345d5..9101928 100644 --- a/src/uml/uml_driver.c +++ b/src/uml/uml_driver.c @@ -2198,6 +2198,18 @@ static virDriver umlDriver = { NULL, /* qemuDomainMonitorCommand */ }; +static int +umlVMFilterRebuild(virConnectPtr conn ATTRIBUTE_UNUSED, + virHashIterator iter, void *data) +{ + struct uml_driver *driver = uml_driver; + + umlDriverLock(driver); + virHashForEach(uml_driver->domains.objs, iter, data); + umlDriverUnlock(driver); + + return 0; +} static virStateDriver umlStateDriver = { .name = "UML", @@ -2207,8 +2219,14 @@ static virStateDriver umlStateDriver = { .active = umlActive, }; +static virNWFilterCallbackDriver umlCallbackDriver = { + .name = "UML", + .vmFilterRebuild = umlVMFilterRebuild, +}; + int umlRegister(void) { virRegisterDriver(&umlDriver); virRegisterStateDriver(&umlStateDriver); + virNWFilterRegisterCallbackDriver(&umlCallbackDriver); return 0; } -- 1.7.1

2 1

[libvirt] [PATCH] virsh: Use virBuffer for generating XML
by Jiri Denemark 14 Sep '10

14 Sep '10

cmdAttachInterface and cmdAttachDisk still used vshRealloc and sprintf for generating XML, which is hardly maintainable. Let's get rid of this old code. --- tools/virsh.c | 152 ++++++++++++++++++++------------------------------------ 1 files changed, 54 insertions(+), 98 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 57ea618..9eb1e51 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -7874,8 +7874,9 @@ cmdAttachInterface(vshControl *ctl, const vshCmd *cmd) virDomainPtr dom = NULL; char *mac, *target, *script, *type, *source; int typ, ret = FALSE; - char *buf = NULL, *tmp = NULL; unsigned int flags; + virBuffer buf = VIR_BUFFER_INITIALIZER; + char *xml; if (!vshConnectionUsability(ctl, ctl->conn)) goto cleanup; @@ -7903,52 +7904,40 @@ cmdAttachInterface(vshControl *ctl, const vshCmd *cmd) } /* Make XML of interface */ - tmp = vshMalloc(ctl, 1); - buf = vshMalloc(ctl, strlen(type) + 25); - sprintf(buf, " <interface type='%s'>\n" , type); + virBufferVSprintf(&buf, "<interface type='%s'>\n" , type); - tmp = vshRealloc(ctl, tmp, strlen(source) + 28); - if (typ == 1) { - sprintf(tmp, " <source network='%s'/>\n", source); - } else if (typ == 2) { - sprintf(tmp, " <source bridge='%s'/>\n", source); - } - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); + if (typ == 1) + virBufferVSprintf(&buf, " <source network='%s'/>\n", source); + else if (typ == 2) + virBufferVSprintf(&buf, " <source bridge='%s'/>\n", source); - if (target != NULL) { - tmp = vshRealloc(ctl, tmp, strlen(target) + 24); - sprintf(tmp, " <target dev='%s'/>\n", target); - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); - } + if (target != NULL) + virBufferVSprintf(&buf, " <target dev='%s'/>\n", target); + if (mac != NULL) + virBufferVSprintf(&buf, " <mac address='%s'/>\n", mac); + if (script != NULL) + virBufferVSprintf(&buf, " <script path='%s'/>\n", script); - if (mac != NULL) { - tmp = vshRealloc(ctl, tmp, strlen(mac) + 25); - sprintf(tmp, " <mac address='%s'/>\n", mac); - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); - } + virBufferAddLit(&buf, "</interface>\n"); - if (script != NULL) { - tmp = vshRealloc(ctl, tmp, strlen(script) + 25); - sprintf(tmp, " <script path='%s'/>\n", script); - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); + if (virBufferError(&buf)) { + vshPrint(ctl, "%s", _("Failed to allocate XML buffer")); + return FALSE; } - buf = vshRealloc(ctl, buf, strlen(buf) + 19); - strcat(buf, " </interface>\n"); + xml = virBufferContentAndReset(&buf); if (vshCommandOptBool(cmd, "persistent")) { flags = VIR_DOMAIN_DEVICE_MODIFY_CONFIG; if (virDomainIsActive(dom) == 1) flags |= VIR_DOMAIN_DEVICE_MODIFY_LIVE; - ret = virDomainAttachDeviceFlags(dom, buf, flags); + ret = virDomainAttachDeviceFlags(dom, xml, flags); } else { - ret = virDomainAttachDevice(dom, buf); + ret = virDomainAttachDevice(dom, xml); } + VIR_FREE(xml); + if (ret != 0) { vshError(ctl, "%s", _("Failed to attach interface")); ret = FALSE; @@ -7960,8 +7949,7 @@ cmdAttachInterface(vshControl *ctl, const vshCmd *cmd) cleanup: if (dom) virDomainFree(dom); - VIR_FREE(buf); - VIR_FREE(tmp); + virBufferFreeAndReset(&buf); return ret; } @@ -8126,9 +8114,10 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd) virDomainPtr dom = NULL; char *source, *target, *driver, *subdriver, *type, *mode; int isFile = 0, ret = FALSE; - char *buf = NULL, *tmp = NULL; unsigned int flags; char *stype; + virBuffer buf = VIR_BUFFER_INITIALIZER; + char *xml; if (!vshConnectionUsability(ctl, ctl->conn)) goto cleanup; @@ -8167,77 +8156,45 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd) } /* Make XML of disk */ - tmp = vshMalloc(ctl, 1); - buf = vshMalloc(ctl, 23); - if (isFile) { - sprintf(buf, " <disk type='file'"); - } else { - sprintf(buf, " <disk type='block'"); - } - - if (type) { - tmp = vshRealloc(ctl, tmp, strlen(type) + 13); - sprintf(tmp, " device='%s'>\n", type); - } else { - tmp = vshRealloc(ctl, tmp, 3); - sprintf(tmp, ">\n"); - } - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); - - if (driver) { - tmp = vshRealloc(ctl, tmp, strlen(driver) + 22); - sprintf(tmp, " <driver name='%s'", driver); - } else { - tmp = vshRealloc(ctl, tmp, 25); - sprintf(tmp, " <driver name='phy'"); - } - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); - - if (subdriver) { - tmp = vshRealloc(ctl, tmp, strlen(subdriver) + 12); - sprintf(tmp, " type='%s'/>\n", subdriver); - } else { - tmp = vshRealloc(ctl, tmp, 4); - sprintf(tmp, "/>\n"); - } - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); - - tmp = vshRealloc(ctl, tmp, strlen(source) + 25); - if (isFile) { - sprintf(tmp, " <source file='%s'/>\n", source); - } else { - sprintf(tmp, " <source dev='%s'/>\n", source); - } - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); - - tmp = vshRealloc(ctl, tmp, strlen(target) + 24); - sprintf(tmp, " <target dev='%s'/>\n", target); - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); + virBufferVSprintf(&buf, "<disk type='%s'", + (isFile) ? "file" : "block"); + if (type) + virBufferVSprintf(&buf, " device='%s'", type); + virBufferAddLit(&buf, ">\n"); + + virBufferVSprintf(&buf, " <driver name='%s'", + (driver) ? driver : "phy"); + if (subdriver) + virBufferVSprintf(&buf, " type='%s'", subdriver); + virBufferAddLit(&buf, "/>\n"); + + virBufferVSprintf(&buf, " <source %s='%s'/>\n", + (isFile) ? "file" : "dev", + source); + virBufferVSprintf(&buf, " <target dev='%s'/>\n", target); + if (mode) + virBufferVSprintf(&buf, " <%s/>\n", mode); + + virBufferAddLit(&buf, "</disk>\n"); - if (mode != NULL) { - tmp = vshRealloc(ctl, tmp, strlen(mode) + 11); - sprintf(tmp, " <%s/>\n", mode); - buf = vshRealloc(ctl, buf, strlen(buf) + strlen(tmp) + 1); - strcat(buf, tmp); + if (virBufferError(&buf)) { + vshPrint(ctl, "%s", _("Failed to allocate XML buffer")); + return FALSE; } - buf = vshRealloc(ctl, buf, strlen(buf) + 13); - strcat(buf, " </disk>\n"); + xml = virBufferContentAndReset(&buf); if (vshCommandOptBool(cmd, "persistent")) { flags = VIR_DOMAIN_DEVICE_MODIFY_CONFIG; if (virDomainIsActive(dom) == 1) flags |= VIR_DOMAIN_DEVICE_MODIFY_LIVE; - ret = virDomainAttachDeviceFlags(dom, buf, flags); + ret = virDomainAttachDeviceFlags(dom, xml, flags); } else { - ret = virDomainAttachDevice(dom, buf); + ret = virDomainAttachDevice(dom, xml); } + VIR_FREE(xml); + if (ret != 0) { vshError(ctl, "%s", _("Failed to attach disk")); ret = FALSE; @@ -8249,8 +8206,7 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd) cleanup: if (dom) virDomainFree(dom); - VIR_FREE(buf); - VIR_FREE(tmp); + virBufferFreeAndReset(&buf); return ret; } -- 1.7.2.3

2 2

[libvirt] [PATCH] Use SED variable for `sed` binary in src/Makefile
by Mitchell Hashimoto 14 Sep '10

14 Sep '10

Hi, I've been trying to get libvirt (client) to cleanly/easily compile on BSD-based systems (in this case OS X). "./configure" runs fine but the "make" caused an error with `sed` since BSD sed was reporting some sort of regex error. I realized that the "SED" variable was populated with "gsed" which worked properly. This made the make continue (failed again later, will address that when I can). This is my first contribution to a C-based project and I don't have much experience with autotools other than using them as a consumer. Let me know if anything can be improved. Thank you, Mitchell

4 6

[libvirt] [PATCH 0/3] test cases for spoofing prevention
by gstenzel＠linux.vnet.ibm.com 14 Sep '10

14 Sep '10

The following patches add a set of test cases to verify that several spoofing attacks are prevented by the nwfilter subsystem. In order to have a well defined test machine a virtual disk is installed from scratch over the network. I am currently trying to find a suitable location for the kickstart file. -- Best regards, Gerhard Stenzel, ----------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294

3 13

Re: [libvirt] Question, how to use virDomainQemuMonitorCommand()
by Chris Lalancette 14 Sep '10

14 Sep '10

On 09/07/10 - 04:08:13PM, Lai Jiangshan wrote: > Hi, Chris, > > I saw virDomainQemuMonitorCommand() in libvirt-qemu.c, > I think it will help me to send arbitrary qemu-monitor command to > qemu via libvirtd. > > But how can I use virDomainQemuMonitorCommand()? > Can I use it by just using current tools(virsh or other) without writing any code? Unfortunately, no. There is a bug in the current virsh command that prevents it from properly parsing the command-lines necessary to send monitor commands to the qemu monitor. Until we fix that bug, we won't push the support into virsh. For that reason you will need to write a custom program to call virDomainQemuMonitorCommand as appropriate. The absolute easiest program you can write looks something like (untested): #include <stdio.h> #include <stdlib.h> #include <libvirt/libvirt.h> int main() { virConnectPtr conn; virDomainPtr dom; char *reply; conn = virConnectOpen(NULL); dom = virDomainLookupByName(conn, "mydomain"); virDomainQemuMonitorCommand(dom, "info cpus", &reply, 0); fprintf(stderr, "Reply: %s\n", reply); free(reply); virConnectClose(conn); return 0; } -- Chris Lalancette

4 8

[libvirt] Remote access form windows - Java bindings
by Gandhiraj Natarajan 14 Sep '10

14 Sep '10

Hi I am developing tool to collect information on XenServer which is on Opensuse 11. I am using libvirt-0.4.6.jar and and jna-3.2.4 jar files. I tried to connect from Remote system(Windows) to server, but could not get the connection object. Any configuration needs to be done for remote access ? conn = new Connect("xen+tcp://192.168.10.22/"); it shows the exception Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'virt': The specified module could not be found. at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:164) at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:237) at com.sun.jna.Library$Handler.<init>(Library.java:140) at com.sun.jna.Native.loadLibrary(Native.java:374) at com.sun.jna.Native.loadLibrary(Native.java:359) at org.libvirt.jna.Libvirt.<clinit>(Unknown Source) at org.libvirt.Connect.<clinit>(Unknown Source) at LibvirtCon.main(LibvirtCon.java:29) Help me Regards Gandhiraj Natarajan

3 6

[libvirt] [PATCH] docs: improve wording for the dev guide
by Justin Clift 13 Sep '10

13 Sep '10

Wording tweak suggested by David Jorm, author of the libvirt App Dev Guide. --- docs/devguide.html.in | 14 +++++++------- docs/downloads.html.in | 14 +++++++------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/devguide.html.in b/docs/devguide.html.in index 409952e..6c51c36 100644 --- a/docs/devguide.html.in +++ b/docs/devguide.html.in @@ -4,16 +4,16 @@ <h1>libvirt Application Development Guide</h1> <p> - This is both a guide to developing with libvirt, and a useful - reference document. It is a work in progress, contributed to by the - members of the libvirt team and being authored by a professional - author. + The guide is both a learning tool for developing with libvirt and an + API reference document. It is a work in progress, composed by a + professional author from contributions written by members of the + libvirt team. </p> <p> - Contributors to this are <b>VERY</b> welcome, so if you'd like to - get your name in this and demonstrate your virtualisation prowess, - contributing solidly to the content here will do it. :) + Contributions to the guide are <b>VERY</b> welcome. If you'd like to get + your name on this and demonstrate your virtualisation prowess, a solid + contribution to the content here will do it. :) </p> <h2>Browsable online</h2> diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 66b99e1..2ce1048 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -49,16 +49,16 @@ <h1>libvirt Application Development Guide</h1> <p> - This is both a guide to developing with libvirt, and a useful - reference document. It is a work in progress, contributed to by the - members of the libvirt team and being authored by a professional - author. + The guide is both a learning tool for developing with libvirt and an + API reference document. It is a work in progress, composed by a + professional author from contributions written by members of the + libvirt team. </p> <p> - Contributors to this are <b>VERY</b> welcome, so if you'd like to - get your name in this and demonstrate your virtualisation prowess, - contributing solidly to the content here will do it. :) + Contributions to the guide are <b>VERY</b> welcome. If you'd like to get + your name on this and demonstrate your virtualisation prowess, a solid + contribution to the content here will do it. :) </p> <h2>Downloadable PDF</h2> -- 1.7.2.2

2 2

[libvirt] [PATCH] tests: Fix preprocessor indentation
by Jiri Denemark 13 Sep '10

13 Sep '10

--- Pushed as obvious to fix make syntax-check failure. tests/virbuftest.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/virbuftest.c b/tests/virbuftest.c index d8258fc..db08fc4 100644 --- a/tests/virbuftest.c +++ b/tests/virbuftest.c @@ -70,7 +70,7 @@ mymain(int argc ATTRIBUTE_UNUSED, int ret = 0; -# define DO_TEST(msg, cb, data) \ +#define DO_TEST(msg, cb, data) \ do { \ struct testInfo info = { data }; \ if (virtTestRun("Buf: " msg, 1, cb, &info) < 0) \ -- 1.7.2.2

1 0

[libvirt] QEMU interfaces for image streaming and post-copy block migration
by Anthony Liguori 12 Sep '10

12 Sep '10

Hi, We've got copy-on-read and image streaming working in QED and before going much further, I wanted to bounce some interfaces off of the libvirt folks to make sure our final interface makes sense. Here's the basic idea: Today, you can create images based on base images that are copy on write. With QED, we also support copy on read which forces a copy from the backing image on read requests and write requests. In additional to copy on read, we introduce a notion of streaming a block device which means that we search for an unallocated region of the leaf image and force a copy-on-read operation. The combination of copy-on-read and streaming means that you can start a guest based on slow storage (like over the network) and bring in blocks on demand while also having a deterministic mechanism to complete the transfer. The interface for copy-on-read is just an option within qemu-img create. Streaming, on the other hand, requires a bit more thought. Today, I have a monitor command that does the following: stream <device> <sector offset> Which will try to stream the minimal amount of data for a single I/O operation and then return how many sectors were successfully streamed. The idea about how to drive this interface is a loop like: offset = 0; while offset < image_size: wait_for_idle_time() count = stream(device, offset) offset += count Obviously, the "wait_for_idle_time()" requires wide system awareness. The thing I'm not sure about is 1) would libvirt want to expose a similar stream interface and let management software determine idle time 2) attempt to detect idle time on it's own and provide a higher level interface. If (2), the question then becomes whether we should try to do this within qemu and provide libvirt a higher level interface. A related topic is block migration. Today we support pre-copy migration which means we transfer the block device and then do a live migration. Another approach is to do a live migration, and on the source, run a block server using image streaming on the destination to move the device. With QED, to implement this one would: 1) launch qemu-nbd on the source while the guest is running 2) create a qed file on the destination with copy-on-read enabled and a backing file using nbd: to point to the source qemu-nbd 3) run qemu -incoming on the destination with the qed file 4) execute the migration 5) when migration completes, begin streaming on the destination to complete the copy 6) when the streaming is complete, shut down the qemu-nbd instance on the source This is a bit involved and we could potentially automate some of this in qemu by launching qemu-nbd and providing commands to do some of this. Again though, I think the question is what type of interfaces would libvirt prefer? Low level interfaces + recipes on how to do high level things or higher level interfaces? Regards, Anthony Liguori

7 31

[libvirt] Release of libvirt-0.8.4
by Daniel Veillard 10 Sep '10

10 Sep '10

As planned the release is now available on the server at ftp://libvirt.org/libvirt/ This is mostly an enhancement and bug fix release, there is less patches than for usual monthly releases, I guess a number of people had a break in August :-) Features: - various improvements to UML driver (Soren Hansen) Documentation: - docs: fix lxc examples (Serge Hallyn) - docs: mention domain <clock> improvements (Eric Blake) - docs: fix an incorrect keyword in updated hooks page (Justin Clift) - docs: significant expansion of custom hook script information (Justin Clift) Portability - cygwin: build fix (Stefan Berger) - build: allow mingw VPATH build (Eric Blake) - Generate libvirt_qemu.def from libvirt_qemu.syms for MinGW builds (Matthias Bolte) - Only require XDR when building libvirtd or the remote driver (Matthias Bolte) - build-sys: fix build when daemon is disabled by not installing libvirtd.8 (Diego Elio Pettenò) Bug Fixes: - Fix block statistics with newer versions of Xen (Guido Günther) - Fix off-by-1 in QEMU boot arg array handling (Daniel P. Berrange) - bridge: Fix static-only DHCP configuration (Jiri Denemark) - qemu: qemuMonitorJSONEjectMedia(): Fix arguments' type (Luiz Capitulino) - qemu: qemuMonitorJSONMigrate(): Fix arguments' type (Luiz Capitulino) - test: Don't overwrite storage volume target path and key (Matthias Bolte) - build: Fix permissions of sysconfig files (Jiri Denemark) - virsh: remove driver check from attach-disk command (Ryan Harper) - phyp: Bad comparison when checking for existing domain name (Eduardo Otubo) - esx: Fix esxVI_BuildSelectSet's invalid argument check (Matthias Bolte) - spec: Fix undefined with_libnl (Jiri Denemark) - Fix handling of sparse NUMA topologies (Daniel P. Berrange) - qemu: Check for errors when converting PCI address to string (Jiri Denemark) - qemu: Fix JSON migrate_set_downtime command (Jiri Denemark) - uml: fix logic bug in checking reply length (Eric Blake) - xen: Fix scheduler setting problems (Daniel Veillard) - nodedev: Free the right pointers when getting WWNs fails (Jiri Denemark) - nodedev: Fix sysfs paths for vport operations (Dave Allan) - xen: Fix device count on detach (Daniel Berrange) - remote: Fix incorrect use of private data field (Daniel Berrange) - esx: Fix memory leak when looking up an non-existing domain by name (Matthias Bolte) - Fix up qemu domain save/managed save locking. (Chris Lalancette) - qemu: Release PCI slot when detaching disk and net devices (Jiri Denemark) - qemu: Re-reserve all PCI addresses on libvirtd restart (Jiri Denemark) - Close fd's of persistent tap devices (Soren Hansen) - Fix tunnelled migration with qemu running as qemu:qemu. (Chris Lalancette) - Fix valgrind complaints when using kill -SIGHUP on libvirtd (Stefan Berger) - bridge: Fix potential segfault when preparing dnsmasq arguments (Jiri Denemark) - Fix return value usage (Doug Goldstein) - nodeinfo: skip offline CPUs (Eric Blake) - Do not use boot=on on IDE device (Daniel Veillard) Improvements: - virsh: Option for overriding disk type in attach-disk (Jiri Denemark) - Explicitly pass uml_dir argument to user-mode-linux (Soren Hansen) - Fix dependancies for remote generated files (Daniel P. Berrange) - Ensure remote daemon unions are always non-zero length (Daniel P. Berrange) - Add nwfilter support to UML driver (Soren Hansen) - esx: Use SessionIsActive when available (Matthias Bolte) - esx: Fall back to path as key when QueryVirtualDiskUuid isn't available (Matthias Bolte) - mingw: match recent changes in spec file (Eric Blake) - Update of localization files (Daniel Veillard) - esx: Use the VirtualDisk UUID as storage volume key (Matthias Bolte) - esx: Add .vmdk storage volume creation (Matthias Bolte) - OpenVZ: add ethernet interface type support (Jean-Baptiste Rouault) - esx: Rework datastore path parsing and handling (Matthias Bolte) - esx: Fix generator for string return values (Matthias Bolte) - build: add some modules (Eric Blake) - Use global directory as UML's monitorDir for privileged connections (Soren Hansen) - maint: track moved file (Eric Blake) - Add tests for Xen's blktap2 implementation (Jim Fehlig) - Add blktap2 support to xend driver (Jim Fehlig) - esx: Map the .vmx annotation to the domain XML description (Matthias Bolte) - esx: Add read-only storage volume access (Matthias Bolte) - Move libvirt-guests init script and config to tools (Jiri Denemark) - Support virDomainAttachDevice and virDomainDetachDevice for disks in UML (Soren Hansen) - Log return value for virConnectGetCapabilities (Daniel P. Berrange) - Try harder to send RPC error message back to client (Daniel P. Berrange) - Add explicit warning messages when failing to serialize to XDR (Daniel P. Berrange) - Allow chardev of type 'file' for UML domains. (Soren Hansen) - esx: Improve object-by-type lookup performance (Matthias Bolte) - xen tests: Fix PV-VFB tests with RHEL-5 API (Jiri Denemark) - xen tests: Fix missing "type ioemu" with rhel5-api (Jiri Denemark) - nodeinfotest: Print libvirt error on failure (Jiri Denemark) - xenapi: support xenapi 5.6.0 headers (Eric Blake) - Add support for -enable-kqemu flag (Daniel P. Berrange) - esx: Use MD5 sum of mount path as storage pool UUID (Matthias Bolte) - esx: Make sure dumpxml outputs proper ID for active domains (Matthias Bolte) - Add actions to virDomainLifecycle enum (Jim Fehlig) - vbox: add location used in rpmfusion release (Eric Blake) - storage: add support for Vendor and Model in XML (Patrick Dignan) - qemu: Fix copy&paste error in warning message (Jiri Denemark) - nwfilter: extend nwfilter reload support (Stefan Berger) - esx: Explicitly disable unused floppy devices (Matthias Bolte) - phyp: Add rudimentary network driver (Eduardo Otubo) - Make umlConnectTapDevice ask brAddTap for a persistent tap device. (Soren Hansen) - Make sure all command line arguments get passed to UML (Soren Hansen) - nwfilter: Discard class D,E IP addresses when sniffing pkts (Stefan Berger) - nwfilter: serialize execution of scripts with ebtables cmds (Stefan Berger) - Move the tunnelled migration unix socket to /var/lib/libvirt/qemu (Chris Lalancette) - qemu: avoid calling the balloon info command if disabled (Daniel Veillard) - bridge: Add --dhcp-no-override option to dnsmasq (Jiri Denemark) - esx: Improve VMX file name parsing and formatting (Matthias Bolte) - esx: Split VMX code into a general and an ESX specific part (Matthias Bolte) - allow memballoon type of none to desactivate it (Daniel Veillard) - Add a detailed message when tap device add fails (Doug Goldstein) - qemu: Hack around asynchronous device_del (Jiri Denemark) - build-sys: only build the test programs during the check phase. (Diego Elio Pettenò) - Add "ubd" to the list of disk prefixes (Soren Hansen) - Extend virSocketParseAddr() to allow a NULL result pointer (Daniel Veillard) - bootloader_args is named bootargs in xen-xm (Philipp Hahn) - Fix return value usage (Doug Goldstein) - qemu: improve error if tun device is missing (Doug Goldstein) - build: rerun bootstrap if po/Makevars got nuked (Eric Blake) Cleanups: - Remove hack to get static binaries in DV environment (Daniel Veillard) - build: avoid uninitialized variable warning (Eric Blake) - vbox: factor a large function (Eric Blake) - lxc: avoid large stacks with veth creation (Eric Blake) - openvz: use virAsprintf to avoid large stacks (Eric Blake) - openvz: formatting cleanups (Eric Blake) - network: use virAsprintf when appropriate (Eric Blake) - Move hextobin as virHexToBin to util.c (Matthias Bolte) - Rename qemudShrinkDisks to virDomainDiskRemove and move to domain_conf.c (Soren Hansen) - xml2sexprtest: Remove graphics from unrelated tests (Jiri Denemark) - xenapi: Fix compile error in previous commit (Matthias Bolte) - qemu: Remove code duplication (Jiri Denemark) - vbox: factor a large function (Eric Blake) - xenapi: avoid sprintf (Eric Blake) - storage: avoid s[n]printf (Eric Blake) - maint: whitespace cleanups (Eric Blake) - build: delete dead comments (Eric Blake) - nwfilter: use consistent OOM reporting (Eric Blake) - build: fix compiler warning (Eric Blake) - build: fix AppArmor compilation (Jamie Strandboge) - Avoid unnecessary bootstrap runs in VPATH builds (Jiri Denemark) - maint: update an email address preference (Eric Blake) - phyp: refactor phypListDomainsGeneric to eliminate buffer overflow (Eduardo Otubo) Thanks everybody who helped for the release with patches, bug reports or documentation ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] Best place to put links to the libvirt App Dev Guide?
by Justin Clift 10 Sep '10

10 Sep '10

Hi guys, Where's the best place in the libvirt.org menu structure, to point people to the (developing) libvirt App Dev Guide? My initial thinking is: a) Have a link to the .pdf in the Downloads section + b) Maybe a new top title section like: Documentation -> "Dev Guide" With links to the html, html (one big page), and pdf files. Sound reasonable? Regards and best wishes, Justin Clift

5 8