September 2010 - Devel - libvirt List Archives

[libvirt] heads up: tag v0.8.4 moved
by Eric Blake 23 Sep '10

23 Sep '10

If you recently cloned libvirt.git, you may have inadvertently picked up a broken v0.8.4 tag. The tag has now been fixed upstream, so clones after today are unaffected; and if you cloned before 0.8.4 was released, you are probably not affected unless you explicitly fetched the broken tag. Here's how to check if you have the bad tag, and if so, how to fix it: case $(git rev-parse v0.8.4 2>/dev/null) in 37b0b91*) git tag -d v0.8.4 && git fetch origin tag v0.8.4 &&\ echo 'tag fixed' ;; v0.8.4) echo 'tag not present, not a problem' ;; 7862e07*) echo 'tag already okay' ;; *) echo 'where did you get this tag from?' ;; esac -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] [PATCH] nodeinfo: work when hot-plugging is disabled
by Eric Blake 22 Sep '10

22 Sep '10

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=635857. * src/nodeinfo.c (cpu_online): Allow missing directory for all CPUs, not just cpu0. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- src/nodeinfo.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/nodeinfo.c b/src/nodeinfo.c index 65eeb24..3dac9f3 100644 --- a/src/nodeinfo.c +++ b/src/nodeinfo.c @@ -65,7 +65,8 @@ int linuxNodeInfoCPUPopulate(FILE *cpuinfo, /* Return the positive decimal contents of the given * CPU_SYS_PATH/cpu%u/FILE, or -1 on error. If MISSING_OK and the * file could not be found, return 1 instead of an error; this is - * because some machines cannot hot-unplug cpu0. */ + * because some machines cannot hot-unplug cpu0, or because + * hot-unplugging is disabled. */ static int get_cpu_value(unsigned int cpu, const char *file, bool missing_ok) { @@ -113,7 +114,7 @@ cleanup: static int cpu_online(unsigned int cpu) { - return get_cpu_value(cpu, "online", cpu == 0); + return get_cpu_value(cpu, "online", true); } static unsigned long count_thread_siblings(unsigned int cpu) -- 1.7.2.3

2 2

[libvirt] [PATCH] Set sensible defaults for cpu match and feature policy
by Daniel P. Berrange 22 Sep '10

22 Sep '10

To enable the CPU XML from the capabilities to be pasted directly into the guest XML with no editing, pick a sensible default for match and feature policy. The CPU match will be exact and the feature policy will be require. This should ensure safety for migration and give DWIM semantics for users * src/conf/cpu_conf.c: Default to exact match and require policy --- src/conf/cpu_conf.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c index 3274659..68d3daf 100644 --- a/src/conf/cpu_conf.c +++ b/src/conf/cpu_conf.c @@ -147,12 +147,10 @@ virCPUDefParseXML(const xmlNodePtr node, char *match = virXMLPropString(node, "match"); if (!match) { - if (virXPathBoolean("boolean(./model)", ctxt)) { - virCPUReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("Missing match attribute for CPU specification")); - goto error; - } - def->match = -1; + if (virXPathBoolean("boolean(./model)", ctxt)) + def->match = VIR_CPU_MATCH_EXACT; + else + def->match = -1; } else { def->match = virCPUMatchTypeFromString(match); VIR_FREE(match); @@ -251,7 +249,10 @@ virCPUDefParseXML(const xmlNodePtr node, char *strpolicy; strpolicy = virXMLPropString(nodes[i], "policy"); - policy = virCPUFeaturePolicyTypeFromString(strpolicy); + if (strpolicy == NULL) + policy = VIR_CPU_FEATURE_REQUIRE; + else + policy = virCPUFeaturePolicyTypeFromString(strpolicy); VIR_FREE(strpolicy); if (policy < 0) { -- 1.7.2.3

2 1

[libvirt] [PATCH] Enable support for nested SVM
by Daniel P. Berrange 22 Sep '10

22 Sep '10

This enables support for nested SVM using the regular CPU model/features block. If the CPU model or features include 'svm' or 'vmx', then the '-enable-nesting' flag will be added to the QEMU command line. Several of the models already include svm support, but QEMU was just masking out the svm bit silently. So this will enable SVM on such models * src/qemu/qemu_conf.h: flag for -enable-nesting * src/qemu/qemu_conf.c: Use -enable-nesting if VMX or SVM are in the CPUID --- src/qemu/qemu_conf.c | 39 +++++++++++++++++++++++++++++++++++++-- src/qemu/qemu_conf.h | 1 + 2 files changed, 38 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 7a37c70..a2aab95 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1210,6 +1210,8 @@ static unsigned long long qemudComputeCmdFlags(const char *help, flags |= QEMUD_CMD_FLAG_NO_KVM_PIT; if (strstr(help, "-tdf")) flags |= QEMUD_CMD_FLAG_TDF; + if (strstr(help, "-enable-nesting")) + flags |= QEMUD_CMD_FLAG_NESTING; if (strstr(help, ",menu=on")) flags |= QEMUD_CMD_FLAG_BOOT_MENU; @@ -3494,13 +3496,36 @@ error: } +#define CPUID_FUNCTION_SVM 0x80000001 +#define CPUID_ECX_SVM 0x00000004 + +#define CPUID_FUNCTION_VMX 0x00000001 +#define CPUID_ECX_VMX 0x00000020 + +static bool qemuCpuHasHwVirt(union cpuData *data) +{ + int i; + for (i = 0 ; i < data->x86.basic_len ; i++) { + if (data->x86.basic[i].function == CPUID_FUNCTION_VMX && + (data->x86.basic[i].ecx & CPUID_ECX_VMX)) + return true; + } + for (i = 0 ; i < data->x86.extended_len ; i++) { + if (data->x86.extended[i].function == CPUID_FUNCTION_SVM && + (data->x86.extended[i].ecx & CPUID_ECX_SVM)) + return true; + } + return false; +} + static int qemuBuildCpuArgStr(const struct qemud_driver *driver, const virDomainDefPtr def, const char *emulator, unsigned long long qemuCmdFlags, const struct utsname *ut, - char **opt) + char **opt, + bool *hasHwVirt) { const virCPUDefPtr host = driver->caps->host.cpu; virCPUDefPtr guest = NULL; @@ -3511,6 +3536,8 @@ qemuBuildCpuArgStr(const struct qemud_driver *driver, virBuffer buf = VIR_BUFFER_INITIALIZER; int i; + *hasHwVirt = false; + if (def->cpu && def->cpu->model) { if (qemudProbeCPUModels(emulator, qemuCmdFlags, ut->machine, &ncpus, &cpus) < 0) @@ -3552,6 +3579,8 @@ qemuBuildCpuArgStr(const struct qemud_driver *driver, if (cpuDecode(guest, data, cpus, ncpus, preferred) < 0) goto cleanup; + *hasHwVirt = qemuCpuHasHwVirt(data); + virBufferVSprintf(&buf, "%s", guest->model); for (i = 0; i < guest->nfeatures; i++) { char sign; @@ -3678,6 +3707,7 @@ int qemudBuildCommandLine(virConnectPtr conn, char *cpu; char *smp; int last_good_net = -1; + bool hasHwVirt = false; uname_normalize(&ut); @@ -3871,13 +3901,18 @@ int qemudBuildCommandLine(virConnectPtr conn, ADD_ARG_LIT(def->os.machine); } - if (qemuBuildCpuArgStr(driver, def, emulator, qemuCmdFlags, &ut, &cpu) < 0) + if (qemuBuildCpuArgStr(driver, def, emulator, qemuCmdFlags, + &ut, &cpu, &hasHwVirt) < 0) goto error; if (cpu) { ADD_ARG_LIT("-cpu"); ADD_ARG_LIT(cpu); VIR_FREE(cpu); + + if ((qemuCmdFlags & QEMUD_CMD_FLAG_NESTING) && + hasHwVirt) + ADD_ARG_LIT("-enable-nesting"); } if (disableKQEMU) diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index 2c9e608..16f72f5 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -93,6 +93,7 @@ enum qemud_cmd_flags { QEMUD_CMD_FLAG_NODEFCONFIG = (1LL << 37), /* -nodefconfig */ QEMUD_CMD_FLAG_BOOT_MENU = (1LL << 38), /* -boot menu=on support */ QEMUD_CMD_FLAG_ENABLE_KQEMU = (1LL << 39), /* -enable-kqemu flag */ + QEMUD_CMD_FLAG_NESTING = (1LL << 40), /* -enable-nesting (SVM/VMX) */ }; /* Main driver state */ -- 1.7.2.3

2 1

[libvirt] [PATCH] nwfilter: fix an bug appearing on big endian machines
by Stefan Berger 22 Sep '10

22 Sep '10

Either one of the following patches fixes a bug appearing on big endian machines where the returned XML is not the one that is expected (see test/nwfilterxml2xmltest). The problem is due to for example the casting of a pointers to unsigned integers to void * and then back to 16 bit integers. I have prepared 2 different solutions for the problem. I think the one with the union is the better one, which I am posting before the shorted solution. Both solutions make the nwfilterxml2xmltest pass on a ppc64 machine. Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com> Index: libvirt-acl/src/conf/nwfilter_conf.c =================================================================== --- libvirt-acl.orig/src/conf/nwfilter_conf.c +++ libvirt-acl/src/conf/nwfilter_conf.c @@ -379,9 +379,14 @@ virNWFilterPoolObjRemove(virNWFilterPool } } +union data { + void *v; + char *c; + unsigned char *uc; + unsigned int ui; +}; - -typedef bool (*valueValidator)(enum attrDatatype datatype, void *valptr, +typedef bool (*valueValidator)(enum attrDatatype datatype, union data *valptr, virNWFilterRuleDefPtr nwf); typedef bool (*valueFormatter)(virBufferPtr buf, virNWFilterRuleDefPtr nwf); @@ -407,18 +412,18 @@ static const struct int_map macProtoMap[ static bool -checkMacProtocolID(enum attrDatatype datatype, void *value, +checkMacProtocolID(enum attrDatatype datatype, union data *value, virNWFilterRuleDefPtr nwf ATTRIBUTE_UNUSED) { int32_t res = -1; if (datatype == DATATYPE_STRING) { - if (intMapGetByString(macProtoMap, (char *)value, 1, &res) == 0) + if (intMapGetByString(macProtoMap, value->c, 1, &res) == 0) res = -1; datatype = DATATYPE_UINT16; } else if (datatype == DATATYPE_UINT16 || datatype == DATATYPE_UINT16_HEX) { - res = (uint32_t)*(uint16_t *)value; + res = value->ui; if (res < 0x600) res = -1; } @@ -485,10 +490,10 @@ checkValidMask(unsigned char *data, int static bool checkMACMask(enum attrDatatype datatype ATTRIBUTE_UNUSED, - void *macMask, + union data *macMask, virNWFilterRuleDefPtr nwf ATTRIBUTE_UNUSED) { - return checkValidMask((unsigned char *)macMask, 6); + return checkValidMask(macMask->uc, 6); } @@ -511,18 +516,18 @@ static const struct int_map arpOpcodeMap static bool arpOpcodeValidator(enum attrDatatype datatype, - void *value, + union data *value, virNWFilterRuleDefPtr nwf) { int32_t res = -1; if (datatype == DATATYPE_STRING) { - if (intMapGetByString(arpOpcodeMap, (char *)value, 1, &res) == 0) + if (intMapGetByString(arpOpcodeMap, value->c, 1, &res) == 0) res = -1; datatype = DATATYPE_UINT16; } else if (datatype == DATATYPE_UINT16 || datatype == DATATYPE_UINT16_HEX) { - res = (uint32_t)*(uint16_t *)value; + res = (uint32_t)value->ui; } if (res != -1) { @@ -570,18 +575,18 @@ static const struct int_map ipProtoMap[] static bool checkIPProtocolID(enum attrDatatype datatype, - void *value, + union data *value, virNWFilterRuleDefPtr nwf) { int32_t res = -1; if (datatype == DATATYPE_STRING) { - if (intMapGetByString(ipProtoMap, (char *)value, 1, &res) == 0) + if (intMapGetByString(ipProtoMap, value->c, 1, &res) == 0) res = -1; datatype = DATATYPE_UINT8_HEX; } else if (datatype == DATATYPE_UINT8 || datatype == DATATYPE_UINT8_HEX) { - res = (uint32_t)*(uint16_t *)value; + res = (uint32_t)value->ui; } if (res != -1) { @@ -615,10 +620,10 @@ formatIPProtocolID(virBufferPtr buf, static bool -dscpValidator(enum attrDatatype datatype, void *val, +dscpValidator(enum attrDatatype datatype, union data *val, virNWFilterRuleDefPtr nwf) { - uint8_t dscp = *(uint16_t *)val; + uint8_t dscp = val->ui; if (dscp > 63) return 0; @@ -1150,7 +1155,8 @@ virNWFilterRuleDetailsParse(xmlNodePtr n nwItemDesc *item; int int_val; unsigned int uint_val; - void *data_ptr = NULL, *storage_ptr; + void *storage_ptr; + union data data; valueValidator validator; char *match = virXMLPropString(node, "match"); nwIPAddress ipaddr; @@ -1206,7 +1212,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n if (uint_val <= 0xff) { *(uint8_t *)storage_ptr = uint_val; found = 1; - data_ptr = &uint_val; + data.ui = uint_val; } else rc = -1; } else @@ -1221,7 +1227,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n if (uint_val <= 0xffff) { *(uint16_t *)storage_ptr = uint_val; found = 1; - data_ptr = &uint_val; + data.ui = uint_val; } else rc = -1; } else @@ -1245,7 +1251,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n *(uint8_t *)storage_ptr = (uint8_t)uint_val; found = 1; - data_ptr = &uint_val; + data.ui = uint_val; } else rc = -1; } else { @@ -1278,7 +1284,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n (nwMACAddressPtr)storage_ptr)) { rc = -1; } - data_ptr = storage_ptr; + data.v = storage_ptr; found = 1; break; @@ -1299,7 +1305,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n *(uint8_t *)storage_ptr = (uint8_t)uint_val; found = 1; - data_ptr = &uint_val; + data.ui = uint_val; } else rc = -1; } else { @@ -1322,7 +1328,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n rc = -1; break; } - data_ptr = prop; + data.c = prop; found = 1; break; @@ -1344,7 +1350,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n *flags = NWFILTER_ENTRY_ITEM_FLAG_EXISTS | flags_set; item->datatype = datatype >> 1; if (validator) { - if (!validator(datatype >> 1, data_ptr, nwf)) { + if (!validator(datatype >> 1, &data, nwf)) { rc = -1; *flags = 0; } =============== 2nd solution ================= Index: libvirt-acl/src/conf/nwfilter_conf.c =================================================================== --- libvirt-acl.orig/src/conf/nwfilter_conf.c +++ libvirt-acl/src/conf/nwfilter_conf.c @@ -181,6 +181,8 @@ static const char dscp_str[] = " #define DSCP dscp_str +#define PARSED_INT_TYPE unsigned int + /** * intMapGetByInt: * @intmap: Pointer to int-to-string map @@ -418,7 +420,7 @@ checkMacProtocolID(enum attrDatatype dat datatype = DATATYPE_UINT16; } else if (datatype == DATATYPE_UINT16 || datatype == DATATYPE_UINT16_HEX) { - res = (uint32_t)*(uint16_t *)value; + res = (uint32_t)*(PARSED_INT_TYPE *)value; if (res < 0x600) res = -1; } @@ -522,7 +524,7 @@ arpOpcodeValidator(enum attrDatatype dat datatype = DATATYPE_UINT16; } else if (datatype == DATATYPE_UINT16 || datatype == DATATYPE_UINT16_HEX) { - res = (uint32_t)*(uint16_t *)value; + res = (uint32_t)*(PARSED_INT_TYPE *)value; } if (res != -1) { @@ -581,7 +583,7 @@ static bool checkIPProtocolID(enum attrD datatype = DATATYPE_UINT8_HEX; } else if (datatype == DATATYPE_UINT8 || datatype == DATATYPE_UINT8_HEX) { - res = (uint32_t)*(uint16_t *)value; + res = (uint32_t)*(PARSED_INT_TYPE *)value; } if (res != -1) { @@ -618,7 +620,7 @@ static bool dscpValidator(enum attrDatatype datatype, void *val, virNWFilterRuleDefPtr nwf) { - uint8_t dscp = *(uint16_t *)val; + uint8_t dscp = *(PARSED_INT_TYPE *)val; if (dscp > 63) return 0; @@ -1149,7 +1151,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n enum virNWFilterEntryItemFlags *flags ,match_flag = 0, flags_set = 0; nwItemDesc *item; int int_val; - unsigned int uint_val; + PARSED_INT_TYPE uint_val; void *data_ptr = NULL, *storage_ptr; valueValidator validator; char *match = virXMLPropString(node, "match");

2 2

[libvirt] XML support for arbitrary command line arguments
by Harsh Bora 22 Sep '10

22 Sep '10

Hi, Is there a way by which I can pass arbitrary command line args to a hypervisor (Qemu), and let the hypervisor decide what to do with it? I mean, is there a generic XML tag define which can be used to specify 'n' number of command line args which are blindly passed to hypervisor to process? regards, Harsh

5 12

[libvirt] [PATCH 00/12] Implement memory control api
by Nikunj A. Dadhania 22 Sep '10

22 Sep '10

This patch series implement public api for controlling various memory tunables exported by the OS. This is based on the following RFC[1]. * Implement virDomainSetMemoryParameters api * Provide implementation for remote, QEmu and LXC drivers * Enable memory controller support fro QEmu * virsh command for runtime changes to the memory parameters * Domain configuration parsing for memory control parameters * Cgroup memory controller code for memory hard_limit/soft_limit, swap hard_limit To Do * Python bindings is just a place holder, need to implement * virDomainGetMemoryParameters 1. https://www.redhat.com/archives/libvir-list/2010-August/msg00607.html 2. https://www.redhat.com/archives/libvir-list/2010-August/msg00699.html --- Nikunj A. Dadhania (12): Adding virDomainSetMemoryParameters API Adding structure for virDomainSetMemoryParameter Adds xml entries for memory tunables XML parsing for memory tunables Hand-coded python bindings for virDomainSetMemoryParameters Implement driver interface domainSetMemoryParamters for QEmu Implement cgroup memory controller tunables Adding memtunables to libvirt-lxc command Adding memtunables to qemuSetupCgroup Adding memtune command to virsh tool Implements virDomainSetMemoryParameters for the remote driver Implement domainSetMemoryParameters function daemon/remote.c | 66 +++++++++++++++++ daemon/remote_dispatch_prototypes.h | 8 ++ daemon/remote_dispatch_table.h | 5 + docs/schemas/domain.rng | 31 ++++++++ include/libvirt/libvirt.h.in | 56 ++++++++++++++ python/generator.py | 1 python/libvirt-override-api.xml | 6 ++ python/libvirt-override.c | 7 ++ src/conf/domain_conf.c | 50 +++++++++++-- src/conf/domain_conf.h | 12 ++- src/driver.h | 6 ++ src/esx/esx_driver.c | 1 src/esx/esx_vmx.c | 30 ++++---- src/libvirt.c | 48 ++++++++++++ src/libvirt_private.syms | 6 ++ src/libvirt_public.syms | 5 + src/lxc/lxc_controller.c | 24 ++++++ src/lxc/lxc_driver.c | 101 ++++++++++++++++++++++++-- src/openvz/openvz_driver.c | 9 +- src/phyp/phyp_driver.c | 1 src/qemu/qemu.conf | 4 + src/qemu/qemu_conf.c | 11 ++- src/qemu/qemu_driver.c | 138 +++++++++++++++++++++++++++++++++-- src/remote/remote_driver.c | 66 +++++++++++++++++ src/remote/remote_protocol.c | 62 +++++++++++++++- src/remote/remote_protocol.h | 36 +++++++++ src/test/test_driver.c | 13 ++- src/uml/uml_conf.c | 2 - src/uml/uml_driver.c | 15 ++-- src/util/cgroup.c | 106 +++++++++++++++++++++++++++ src/util/cgroup.h | 7 ++ src/xen/xen_driver.c | 1 tools/virsh.c | 89 +++++++++++++++++++++++ 33 files changed, 955 insertions(+), 68 deletions(-)

2 21

[libvirt] dnsmasq, dhcp - bug or feature
by Zdenek Styblik 22 Sep '10

22 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, I have network definition like this: <network> <name>default</name> <uuid>5539715b-ae89-c15c-aa2e-2f5a7afd55b8</uuid> <forward mode='route'/> <bridge name='virbr0' stp='on' delay='0' /> <ip address='10.117.9.1' netmask='255.255.255.224'> </ip> </network> and I would assume it means DHCP is off. Even virt-manager claims it's off, yet dnsmasq gets started every time. And what's "worse", it's giving away IP addresses. So, I'm wondering if it's bug or feature or have I missed something? :o) libvirt version is 0.8.4 as I haven't upgraded to 0.8.5 yet. Thanks for reply and have a nice weekend, Zdenek Styblik - -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla(a)turnovfree.net jabber: stybla(a)jabber.turnovfree.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyTx74ACgkQ8MreUbSH7il8agCfRHP4IbW8t4MheQs5JIU4xGgE SmgAni4XwNdfYfYTq2hc1F99Y7sbPyeD =CebK -----END PGP SIGNATURE-----

2 2

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 17 Sep '10

17 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 17 Sep '10

17 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 17 Sep '10

17 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 16 Sep '10

16 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 16 Sep '10

16 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 16 Sep '10

16 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 16 Sep '10

16 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 16 Sep '10

16 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 15 Sep '10

15 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 15 Sep '10

15 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 15 Sep '10

15 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 15 Sep '10

15 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 15 Sep '10

15 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