- Devel - libvirt List Archives

[libvirt] Libvirt guide draft published on libvirt.org
by David Jorm 28 Jan '10

28 Jan '10

I am a tech writer who recently joined the Red Hat team. I have been tasked with assisting in the improvement of libvirt documentation where possible and co-ordinating the development of the libvirt Application Development Guide. The guide was previously in the hands of Dani Coulson, who has since left Red Hat. She got it to a draft stage with a skeletal structure, but as far as I can tell nothing ever reached a publishable state. I've picked up where she left off and re-built the latest guide from the DocBook XML in git. It is now up at: http://libvirt.org/guide/ If you look in the guide, you will notice an awful lot of "TBD" stubs. Contributions to fill these would be greatly appreciated - please email them to me directly. I will chase up with the people who were originally nominated as the responsible parties to try and get some content to flesh out the guide. I don't have a lot of spare temporal bandwidth at the moment, but if there are any docs-related BZs or libvirt issues, feel free to push them my way and i'll do what I can. I think i've made every mistake possible so far in submitting patches, so I know the process by virtue of what-not-to-do. Thanks David

2 3

[libvirt] Libvirt/LXC creation example
by Avi Weit 28 Jan '10

28 Jan '10

Hi, I am looking for a simple example for creating a Linux container (LXC) with a network connection that can be accessed from the outside world. I first tried to set up a bridge and link it with the interface eth0 configured on host via: brctl addif virbr0 eth0 but each time I did that - I lost the connection to the host and could not even ping it. The connection was resumed only when removing the host interface of eth0 from the bridge: brctl delif virbr0 eth0 How can I define the network interfaces to be configured inside the container? How can I setup container IPs? Any full XML example would be appreciated. Thanks - Avi

1 0

[libvirt] [PATCH 0/1] Clean up udev init
by David Allan 28 Jan '10

28 Jan '10

The following patch contains cleanup for the udev init error handling and Matthias' fix for the case in which priv is NULL when shutdown is called. Dave

3 3

[libvirt] [PATCH 0/7] Update hotplug code to use device_add
by Daniel P. Berrange 27 Jan '10

27 Jan '10

I previously changed the command line syntax to use -device for starting guests. The key reason for this was to allow unique names and PCI addresses to be assigned to all devices. I forgot todo the same for hotplug :-( This series is not yet complete, but it goes some of the way towards fixing the hotplug code to use 'device_add' for creating devices. The main remaining problem is that I'm nt assigning aliases to devices, to they all get the name of '(null)'. Obviously I'll fix that before submitting again... Daniel

1 7

[libvirt] [PATCH] support XEN_SYSCTL_INTERFACE_VERSION
by Jim Fehlig 27 Jan '10

27 Jan '10

xen-unstable c/s 20762 bumped XEN_SYSCTL_INTERFACE_VERSION to 7. I don't see how the interface change affects libvirt, other than failing xenHypervisorInit() since version 7 is not tried. The attached patch accommodates the upcoming Xen 4.0 release by checking for XEN_SYSCTL_INTERFACE_VERSION 7. If found, it sets XEN_DOMCTL_INTERFACE_VERSION to 6, which is also new to Xen 4.0. Regards, Jim

2 2

[libvirt] [PATCH 0/1] Clean up udev init
by David Allan 27 Jan '10

27 Jan '10

Matthias' patch made me realize that I didn't write the udev init code as cleanly as I'd like, and the error handling was starting to get a little messy. The attached patch cleans it up. There should be no functional change. Dave

3 3

[libvirt] [PATCH] Add missing sata controller type to domain.rng
by Matthew Booth 27 Jan '10

27 Jan '10

* docs/schemas/domain.rng: Add sata controller type --- docs/schemas/domain.rng | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index 49b57eb..827ff6f 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -529,6 +529,7 @@ <value>fdc</value> <value>ide</value> <value>scsi</value> + <value>sata</value> </choice> </attribute> </optional> -- 1.6.6

2 1

[libvirt] [PATCH] portability to non-glibc: don't use realpath(..., NULL)
by Jim Meyering 27 Jan '10

27 Jan '10

Using realpath like that is not portable, and providing a buffer instead of NULL is wasteful and harder to code properly. Instead, use gnulib's canonicalize_file_name, which does the same job portably: >From 4afea6b59e2be6c28b45ef59a6a2f896eed44dba Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 26 Jan 2010 17:13:45 +0100 Subject: [PATCH] portability to non-glibc: don't use realpath(..., NULL) it causes a NULL-dereference on some systems like Solaris 10. * src/node_device/node_device_linux_sysfs.c. Include <stdlib.h>. (get_sriov_function): Use canonicalize_filen_name, not realpath. * bootstrap (modules): Add canonicalize-lgpl. --- bootstrap | 1 + src/node_device/node_device_linux_sysfs.c | 6 ++++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/bootstrap b/bootstrap index aec5d05..cc3c6ef 100755 --- a/bootstrap +++ b/bootstrap @@ -68,6 +68,7 @@ modules=' areadlink base64 c-ctype +canonicalize-lgpl close connect getaddrinfo diff --git a/src/node_device/node_device_linux_sysfs.c b/src/node_device/node_device_linux_sysfs.c index 33e658d..c1fce5d 100644 --- a/src/node_device/node_device_linux_sysfs.c +++ b/src/node_device/node_device_linux_sysfs.c @@ -24,6 +24,7 @@ #include <fcntl.h> #include <sys/stat.h> +#include <stdlib.h> #include "node_device_driver.h" #include "node_device_hal.h" @@ -242,7 +243,8 @@ out: static int get_sriov_function(const char *device_link, struct pci_config_address **bdf) { - char *device_path = NULL, *config_address = NULL; + char *config_address = NULL; + char *device_path = NULL; char errbuf[64]; int ret = SRIOV_ERROR; @@ -259,7 +261,7 @@ static int get_sriov_function(const char *device_link, } - device_path = realpath(device_link, device_path); + device_path = canonicalize_file_name (device_link); if (device_path == NULL) { memset(errbuf, '\0', sizeof(errbuf)); VIR_ERROR("Failed to resolve device link '%s': '%s'", device_link, -- 1.7.0.rc0.140.gfbe7

2 2

[libvirt] [RFC] [Patch] Support for Linux macvtap device
by Stefan Berger 27 Jan '10

27 Jan '10

Hello! The attached patch provides support for the Linux macvtap device for Qemu by passing a file descriptor to Qemu command line similar to how it is done with a regular tap device. I have modified the network XML code to understand a definition as the following one here: <network> <name>vepanet</name> <uuid>4ebd5168-6321-4757-8397-f6e83484f402</uuid> <extbridge mode='vepa' dev='eth0'/> </network> This XML indicates the device that links to the external bridge, here eth0, and the mode this device is supposed to be set into, here 'vepa'. If 'extbridge' is found in the XML, all other XML elements that have been used so far, i.e., bridge, ip, dhcp, etc., are ignored. The above network description can then be referenced from the virtual machine definition using the typical interface description of type 'network': <interface type='network'> <source network='vepanet'/> <model type='virtio'/> </interface> The above network XML holds the necessary parameters to open a macvtap device. Using command line, one would issue the following command to achieve the same what now libvirt does internally, using a patched version of the 'ip' command: ip link add link eth0 <optional name of if> type macvtap mode vepa This then creates the network interface, i.e., macvtap12, along with entries in /sys/class/net/macvtap12/ where the content of the ifindex file returns the integer necessary to build the /dev/tap%d device to open the file descriptor of and pass to qemu via command line argument. Some details: In libvirt I am first searching for an unused interface name following the template macvtap%d unless the user has provided a name explicitly or the previous macvtap%d is now taken by another VM. Once that has succeeded, I follow the path through the filesystem to open the corresponding /dev/tap%d. Unlike the regular tap device, where the network interface disappears once the corresponding file descriptor is closed, the macvtap device needs explicit tear-down. So, when a VM terminates, I am deleting all macvtap type interface with the MAC address as the interface of the terminating VM. Some further background on this device was recently given here: https://www.redhat.com/archives/libvir-list/2010-January/msg00721.html The macvtap patch for Linux was posted here: http://lkml.org/lkml/2009/12/3/239 I'd be curious about comments on the code. Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>

2 3

[libvirt] [PATCH] qemu_monitor_json.c: avoid an unconditional leak
by Jim Meyering 27 Jan '10

27 Jan '10

Calling virJSONValueFree does not free the memory allocated via this: cmd = qemuMonitorJSONMakeCommand("drive_add", "s:pci_addr", dev, "s:opts", drivestr, NULL); so I added the VIR_FREE: >From 1d272e070b66fc16e2fcc23002879ee268a58a5f Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 27 Jan 2010 09:58:12 +0100 Subject: [PATCH] qemu_monitor_json.c: avoid an unconditional leak * src/qemu/qemu_monitor_json.c (qemuMonitorJSONAttachDrive): Don't leak the buffer behind a virJSONValuePtr. --- src/qemu/qemu_monitor_json.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 8e88c7e..0f970bb 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -1773,6 +1773,7 @@ int qemuMonitorJSONAttachDrive(qemuMonitorPtr mon, ret = -1; virJSONValueFree(cmd); + VIR_FREE(cmd); virJSONValueFree(reply); return ret; } -- 1.7.0.rc0.140.gfbe7

1 0