September 2009 - Devel - libvirt List Archives

[libvirt] [PATCH] Support reporting live interface IP/netmask.
by Laine Stump 06 Oct '09

06 Oct '09

From: root <root(a)vlap.laine.org> This patch adds the flag VIR_INTERFACE_XML_INACTIVE to virInterfaceGetXMLDesc's flags. When it is *not* set (the default), the live interface info will be returned in the XML. in particular, the IP address(es) and netmask(s) will be retrieved by querying the device directly, rather than just reporting what's in the config file. The backend of this is in netcf's new ncf_if_xml_state() function. Any live interface ip address info in the xml will have the property "source" set to "device", eg: <ip address='10.24.0.1' prefix='24' source='device'/> Also, if an interface is currently inactive, no ip addresses will be returned, since an inactive interface device can't be queried for IP addresses (effectively it has none). A difference in the XML from previously - it is now acceptable to have both a dhcp *and* an ip node (or neither) within the protocol node. Before you had to have one or the other, but couldn't have both. Note that you need at least netcf 0.1.2 for this to build and work, and an upcoming release (patches submitted today) for it to work exactly as described above. --- include/libvirt/libvirt.h.in | 4 +++ src/conf/interface_conf.c | 62 ++++++++++++++++++++++------------------- src/conf/interface_conf.h | 1 + src/interface/netcf_driver.c | 8 ++++- src/libvirt.c | 15 +++++++--- tools/virsh.c | 10 +++++- 6 files changed, 63 insertions(+), 37 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 4e63e48..fd0c90b 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -922,6 +922,10 @@ virInterfacePtr virInterfaceLookupByMACString (virConnectPtr conn, const char* virInterfaceGetName (virInterfacePtr iface); const char* virInterfaceGetMACString (virInterfacePtr iface); +typedef enum { + VIR_INTERFACE_XML_INACTIVE = 1 /* dump inactive interface information */ +} virInterfaceXMLFlags; + char * virInterfaceGetXMLDesc (virInterfacePtr iface, unsigned int flags); virInterfacePtr virInterfaceDefineXML (virConnectPtr conn, diff --git a/src/conf/interface_conf.c b/src/conf/interface_conf.c index e646351..b422464 100644 --- a/src/conf/interface_conf.c +++ b/src/conf/interface_conf.c @@ -92,6 +92,7 @@ void virInterfaceDefFree(virInterfaceDefPtr def) VIR_FREE(def->proto.family); VIR_FREE(def->proto.address); VIR_FREE(def->proto.gateway); + VIR_FREE(def->proto.source); VIR_FREE(def); } @@ -272,6 +273,8 @@ virInterfaceDefParseIp(virConnectPtr conn, virInterfaceDefPtr def, "%s", _("Invalid ip address prefix value")); return(-1); } + tmp = virXPathString(conn, "string(./ip[1]/@source)", ctxt); + def->proto.source = tmp; } tmp = virXPathString(conn, "string(./route[1]/@gateway)", ctxt); def->proto.gateway = tmp; @@ -282,22 +285,19 @@ virInterfaceDefParseIp(virConnectPtr conn, virInterfaceDefPtr def, static int virInterfaceDefParseProtoIPv4(virConnectPtr conn, virInterfaceDefPtr def, xmlXPathContextPtr ctxt) { - xmlNodePtr cur; - int ret; + xmlNodePtr dhcp, ip; + int ret = 0; - cur = virXPathNode(conn, "./dhcp", ctxt); - if (cur != NULL) - ret = virInterfaceDefParseDhcp(conn, def, cur, ctxt); - else { - cur = virXPathNode(conn, "./ip", ctxt); - if (cur != NULL) - ret = virInterfaceDefParseIp(conn, def, cur, ctxt); - else { - virInterfaceReportError(conn, VIR_ERR_XML_ERROR, - "%s", _("interface miss dhcp or ip adressing")); - ret = -1; - } - } + dhcp = virXPathNode(conn, "./dhcp", ctxt); + if (dhcp != NULL) + ret = virInterfaceDefParseDhcp(conn, def, dhcp, ctxt); + + if (ret != 0) + return(ret); + + ip = virXPathNode(conn, "./ip", ctxt); + if (ip != NULL) + ret = virInterfaceDefParseIp(conn, def, ip, ctxt); return(ret); } @@ -1005,6 +1005,7 @@ virInterfaceVlanDefFormat(virConnectPtr conn, virBufferPtr buf, static int virInterfaceProtocolDefFormat(virConnectPtr conn ATTRIBUTE_UNUSED, virBufferPtr buf, const virInterfaceDefPtr def) { + char prefixStr[16]; if (def->proto.family == NULL) return(0); virBufferVSprintf(buf, " <protocol family='%s'>\n", def->proto.family); @@ -1015,20 +1016,23 @@ virInterfaceProtocolDefFormat(virConnectPtr conn ATTRIBUTE_UNUSED, virBufferAddLit(buf, " <dhcp peerdns='yes'/>\n"); else virBufferAddLit(buf, " <dhcp/>\n"); - } else { - /* theorically if we don't have dhcp we should have an address */ - if (def->proto.address != NULL) { - if (def->proto.prefix != 0) - virBufferVSprintf(buf, " <ip address='%s' prefix='%d'/>\n", - def->proto.address, def->proto.prefix); - else - virBufferVSprintf(buf, " <ip address='%s'/>\n", - def->proto.address); - } - if (def->proto.gateway != NULL) { - virBufferVSprintf(buf, " <route gateway='%s'/>\n", - def->proto.gateway); - } + } + if (def->proto.address != NULL) { + if (def->proto.prefix != 0) + snprintf(prefixStr, sizeof(prefixStr), "%d", def->proto.prefix); + + virBufferVSprintf(buf, " <ip address='%s'%s%s%s%s%s%s/>\n", + def->proto.address, + def->proto.prefix ? " prefix='" : "", + def->proto.prefix ? prefixStr : "", + def->proto.prefix ? "'" : "", + def->proto.source ? " source='" : "", + def->proto.source ? def->proto.source : "", + def->proto.source ? "'" : ""); + } + if (def->proto.gateway != NULL) { + virBufferVSprintf(buf, " <route gateway='%s'/>\n", + def->proto.gateway); } virBufferAddLit(buf, " </protocol>\n"); return(0); diff --git a/src/conf/interface_conf.h b/src/conf/interface_conf.h index bb9dce4..df871aa 100644 --- a/src/conf/interface_conf.h +++ b/src/conf/interface_conf.h @@ -132,6 +132,7 @@ struct _virInterfaceProtocolDef { char *address; /* ip address */ int prefix; /* ip prefix */ char *gateway; /* route gateway */ + char *source; /* source of address - "device" or "config" (default) */ }; diff --git a/src/interface/netcf_driver.c b/src/interface/netcf_driver.c index ca14fb0..b5c3664 100644 --- a/src/interface/netcf_driver.c +++ b/src/interface/netcf_driver.c @@ -326,7 +326,7 @@ cleanup: } static char *interfaceGetXMLDesc(virInterfacePtr ifinfo, - unsigned int flags ATTRIBUTE_UNUSED) + unsigned int flags) { struct interface_driver *driver = ifinfo->conn->interfacePrivateData; struct netcf_if *iface = NULL; @@ -342,7 +342,11 @@ static char *interfaceGetXMLDesc(virInterfacePtr ifinfo, goto cleanup; } - xmlstr = ncf_if_xml_desc(iface); + if ((flags & VIR_INTERFACE_XML_INACTIVE)) { + xmlstr = ncf_if_xml_desc(iface); + } else { + xmlstr = ncf_if_xml_state(iface); + } if (!xmlstr) { const char *errmsg, *details; int errcode = ncf_error(driver->netcf, &errmsg, &details); diff --git a/src/libvirt.c b/src/libvirt.c index bcb89e1..bd712dc 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -5915,10 +5915,17 @@ virInterfaceGetMACString(virInterfacePtr iface) /** * virInterfaceGetXMLDesc: * @iface: an interface object - * @flags: an OR'ed set of extraction flags, not used yet + * @flags: an OR'ed set of extraction flags. Current valid bits: + * + * VIR_INTERFACE_XML_INACTIVE - return the static configuration, + * suitable for use redefining the + * interface via virInterfaceDefineXML() * - * Provide an XML description of the interface. The description may be reused - * later to redefine the interface with virInterfaceDefineXML(). + * Provide an XML description of the interface. If + * VIR_INTERFACE_XML_INACTIVE is set, the description may be reused + * later to redefine the interface with virInterfaceDefineXML(). If it + * is not set, the ip address and netmask will be the current live + * setting of the interface, not the settings from the config files. * * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case of error. * the caller must free() the returned value. @@ -5935,7 +5942,7 @@ virInterfaceGetXMLDesc(virInterfacePtr iface, unsigned int flags) virLibInterfaceError(NULL, VIR_ERR_INVALID_INTERFACE, __FUNCTION__); return (NULL); } - if (flags != 0) { + if ((flags & ~VIR_INTERFACE_XML_INACTIVE) != 0) { virLibInterfaceError(iface, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } diff --git a/tools/virsh.c b/tools/virsh.c index 3482389..77f1d70 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -2763,7 +2763,7 @@ cmdInterfaceEdit (vshControl *ctl, const vshCmd *cmd) char *doc = NULL; char *doc_edited = NULL; char *doc_reread = NULL; - int flags = 0; + int flags = VIR_INTERFACE_XML_INACTIVE; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) goto cleanup; @@ -3297,6 +3297,7 @@ static const vshCmdInfo info_interface_dumpxml[] = { static const vshCmdOptDef opts_interface_dumpxml[] = { {"interface", VSH_OT_DATA, VSH_OFLAG_REQ, gettext_noop("interface name or MAC address")}, + {"inactive", VSH_OT_BOOL, 0, gettext_noop("show inactive defined XML")}, {NULL, 0, 0, NULL} }; @@ -3306,6 +3307,11 @@ cmdInterfaceDumpXML(vshControl *ctl, const vshCmd *cmd) virInterfacePtr iface; int ret = TRUE; char *dump; + int flags = 0; + int inactive = vshCommandOptBool(cmd, "inactive"); + + if (inactive) + flags |= VIR_INTERFACE_XML_INACTIVE; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) return FALSE; @@ -3313,7 +3319,7 @@ cmdInterfaceDumpXML(vshControl *ctl, const vshCmd *cmd) if (!(iface = vshCommandOptInterface(ctl, cmd, NULL))) return FALSE; - dump = virInterfaceGetXMLDesc(iface, 0); + dump = virInterfaceGetXMLDesc(iface, flags); if (dump != NULL) { printf("%s", dump); free(dump); -- 1.6.2.5

5 16

[libvirt] [RFC] Multi-IQN proposal
by Shyam_Iyer＠Dell.com 06 Oct '09

06 Oct '09

Would this proposal be acceptable ? Example XML schema for an iSCSI storage pool created -- <pool type="iscsi"> <name>dell</name> <uuid>cf354733-b01b-8870-2040-94888640e24d</uuid> <capacity>0</capacity> <allocation>0</allocation> <available>0</available> - <source> <initiator iqnname = "<initiator IQN1>"> <initiator iqnname = "<initiator IQN2>"> ........................................ ........................................ <host name="<iSCSI target hostname or Target IP address>" /> <device path="<iSCSI Target IQN name>" /> </source> - <target> <path>/dev/disk/by-path</path> - <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> Each initiator iqn name can be parsed to create the unique sessions. This should solve the following possibilities -- * possibility of multiple IQNs for a single Guest * option for Guest's own BIOS & initiator to use these IQNs (iSCSI in Guest) * option for hypervisor's initiator to use these IQNs on behalf of the guest (Multi-IQN) Compile tested only. Needs beatification. diff --git a/src/storage_conf.c b/src/storage_conf.c index cb063cc..915e897 100644 --- a/src/storage_conf.c +++ b/src/storage_conf.c @@ -116,6 +116,7 @@ enum { VIR_STORAGE_POOL_SOURCE_DIR = (1<<2), VIR_STORAGE_POOL_SOURCE_ADAPTER = (1<<3), VIR_STORAGE_POOL_SOURCE_NAME = (1<<4), + VIR_STORAGE_POOL_SOURCE_INITIATOR_IQN = (1<<5), }; @@ -537,6 +538,33 @@ virStoragePoolDefParseXML(virConnectPtr conn, goto cleanup; } } + +/* Read the conf here */ + if (options->flags & VIR_STORAGE_POOL_SOURCE_INITATOR_IQN) { + int niqn, i; + + if ((niqn = virXPathNodeSet(conn, "./source/host/initiator", ctxt, &nodeset)) < 0) { + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("cannot extract storage pool source devices")); + goto cleanup; + } + if (VIR_ALLOC_N(ret->source.niqn, niqn) < 0) { + VIR_FREE(nodeset); + virReportOOMError(conn); + goto cleanup; + } + for (i = 0 ; i < niqn ; i++ ) { + xmlChar *name = xmlGetProp(nodeset[i], BAD_CAST "iqnname"); + if (path == NULL) { + VIR_FREE(nodeset); + virStorageReportError(conn, VIR_ERR_XML_ERROR, + "%s", _("missing storage pool source device path")); + goto cleanup; + } + ret->source.initiator[i].iqnname = (char *)name; + } + } if (options->flags & VIR_STORAGE_POOL_SOURCE_DEVICE) { xmlNodePtr *nodeset = NULL; int nsource, i; diff --git a/src/storage_conf.h b/src/storage_conf.h index 421d305..c2504be 100644 --- a/src/storage_conf.h +++ b/src/storage_conf.h @@ -202,7 +202,12 @@ struct _virStoragePoolSourceDevice { } geometry; }; - +/* Initiator Attributes */ +typedef virStoragePoolSourceInitiatorAttr *virStoragePoolSourceInitiatorAttrPtr; +struct virStoragePoolSourceInitiatorAttr { + char *iqnname; + /* We could put other initiator specific things here */ +} typedef struct _virStoragePoolSource virStoragePoolSource; typedef virStoragePoolSource *virStoragePoolSourcePtr; @@ -214,6 +219,9 @@ struct _virStoragePoolSource { int ndevice; virStoragePoolSourceDevicePtr devices; + /*And either one or more initiators*/ + virStoragePoolSourceInitiatorAttrPtr initiator; + /* Or a directory */ char *dir;

4 9

[libvirt] Update libvirt API and refs XML files
by Matthias Bolte 02 Oct '09

02 Oct '09

Commit 47c8709564ac3f2ec5b4a3830ac213e69b4a44d5 "Fix up a few typos in the tree" triggered changes in docs/libvirt-api.xml and docs/libvirt-refs.xml. The attached patch contains this changes. The files docs/libvirt-api.xml and docs/libvirt-refs.xml are generated by apibuild.py, why are this generated files under version control? Matthias

6 8

[libvirt] [PATCH 00/11] Generic data stream handling
by Daniel P. Berrange 02 Oct '09

02 Oct '09

The following series of patches introduce support for generic data streams in the libvirt API, the remote protocol, client & daemon. The public API takes the form of a new object virStreamPtr and methods to read/write/close it The remote protocol was the main hard bit. Since the protocol allows multiple concurrent API calls on a single connection, this needed to also allow concurrent data streams. It is also not acceptable for a large data stream to block other traffic while it is transferring. Thus, we introduce a new protocol message type 'REMOTE_STREAM' to handle transfer for the stream data. A method involving a data streams starts off in the normal way with a REMOTE_CALL to the server, and a REMOTE_REPLY response message. If this was successful, there now follows the data stream traffic. For outgoing streams (data from client to server), the client will send zero or more REMOTE_STREAM packets containing the data with status == REMOTE_CONTINUE. These are asynchronous and not acknowledged by the server. At any time the server may send an async message with a type of REMOTE_STREAM and status of REMOTE_ERROR. This indicates to the client that the transfer is aborting at server request. If the client wishes to abort, it can send the server a REMOTE_STREAM+REMOTE_ERROR message. If the client finishes its data transfer, it will send a final REMOTE_STREAM+REMOTE_OK message, and the server will respond with the same. This full roundtrip handshake ensures any async error messages are guarenteed to be flushed For incoming data streams (data from server to client), the server sends zero or more REMOTE_STREAM packets containing the data with status == REMOTE_CONTINUE. These are asynchronous and not acknowledged by the client. At any time the client may send an async message with a type of REMOTE_STREAM and status of REMOTE_ERROR. This indicates to the server that the transfer is aborting at client request. If the server wishes to abort, it can send the server a REMOTE_STREAM+REMOTE_ERROR message. When the server finishes its data transfer, it will send a final REMOTE_STREAM+REMOTE_CONTINUE message ewith a data length of zero (ie EOF). The client will then send a REMOTE_STREAM+REMOTE_OK packet and the server will respond with the same. This full roundtrip handshake ensures any async error messages are guarenteed to be flushed This all ensures that multiple data streams can be active in parallel, and with a maximum data packet size of 256 KB, no single stream can cause too much latency on the connection for other API calls/streams. The only thing it does not allow for is one API method to use two or more streams. These may be famous last words, but I don't think that use case will be neccessary for any of our APIs... The last 5 patches with a subject of [DEMO] are *NOT* intended to be committed to the repository. They merely demonstrate the use of data streams for a couple of hypothetical file upload and download APIs. Actually they were mostly to allow me to test the code streams code without messing around with the QEMU migration code. The immediate use case for this data stream code is Chris' QEMU migration patchset. The next use case is to allow serial console access to be tunnelled over libvirtd, eg to make 'virsh console GUEST' work remotely. This use case is why I included the support for non-blocking data streams and event loop integration (not required for Chris' migration use case) Anyway, assuming Chris confirms that I've not broken his code, then patches 1-6 are targetted for this next release. .x-sc_avoid_write | 3 include/libvirt/libvirt.h | 101 ++++ include/libvirt/libvirt.h.in | 101 ++++ po/POTFILES.in | 1 qemud/Makefile.am | 1 qemud/dispatch.c | 131 ++++++ qemud/dispatch.h | 17 qemud/event.c | 54 +- qemud/qemud.c | 56 +- qemud/qemud.h | 33 + qemud/remote.c | 237 ++++++++++- qemud/remote.h | 1 qemud/remote_dispatch_args.h | 2 qemud/remote_dispatch_prototypes.h | 153 +++++++ qemud/remote_dispatch_table.h | 10 qemud/remote_generate_stubs.pl | 1 qemud/remote_protocol.c | 18 qemud/remote_protocol.h | 20 qemud/remote_protocol.x | 57 ++ qemud/stream.c | 605 +++++++++++++++++++++++++++++ qemud/stream.h | 53 ++ src/datatypes.c | 59 ++ src/datatypes.h | 33 + src/driver.h | 40 + src/esx/esx_driver.c | 2 src/libvirt.c | 769 +++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 2 src/libvirt_public.syms | 18 src/lxc_driver.c | 2 src/opennebula/one_driver.c | 2 src/openvz_driver.c | 2 src/qemu_driver.c | 2 src/remote_internal.c | 601 ++++++++++++++++++++++++++++ src/test.c | 477 ++++++++++++++++++++++ src/uml_driver.c | 2 src/vbox/vbox_tmpl.c | 3 src/virsh.c | 164 +++++++ src/xen_unified.c | 2 tests/eventtest.c | 19 39 files changed, 3783 insertions(+), 71 deletions(-) Regards, Daniel

5 43

[libvirt] Tunnelled migration
by Chris Lalancette 02 Oct '09

02 Oct '09

At long last, now that the stream stuff is committed to the tree, I can repost the tunnelled migration patches. Note that these patches will conflict in some places with danpb's previously posted "PEER2PEER" patches, but it should be easy to resolve the differences. V2: Rework the monitor patch to be an API Use the new monitor API Remove silly use of qemuEscapeMonitorArgs()

2 6

[libvirt] Silently ignored virDomainRestore failures
by Charles Duffy 02 Oct '09

02 Oct '09

Howdy, all. I maintain a test infrastructure which makes heavy use of virDomainSave and virDomainRestore, and have been seeing occasional cases where my saved images are for some reason not restored correctly -- and, indeed, the incoming migration streams are not even read in their entirety. While this generally appears to be caused by issues outside of libvirt's purview, one unfortunate issue is that libvirt can report success performing a restore even when the operation is effectively an abject failure. Consider the following snippet, taken from one of my /var/log/libvirt/qemu/<domain>.log files: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin USER=root LOGNAME=root /usr/bin/qemu-kvm -S -M pc-0.11 -m 512 -smp 1 <...lots of arguments here...> -incoming exec:cat cat: write error: Broken pipe This leaves a running qemu hosting a catatonic guest -- but the libvirt client (connecting through the Python bindings) received a status of success for the operation given here. libvirt's mechanism for validating a successful restore consists of running a "cont" command on the guest, and then checking virGetLastError(); AIUI, it is expected that the "cont" will not be able to run until the restore is completed, as the monitor should not be responsive until that time. Browsing through qemudMonitorSendCont (and qemudMonitorCommandWithHandler, which it calls), I don't see anything which looks at the log file with the stderr output from qemu to determine whether an error actually occurred. (As an aside, "info history" on the guest's monitor socket indicates that it was indeed issued this "cont"). Should the existing cont+virGetLastError() approach be sufficient to handle this class of error? If not, is there any guidance on what would comprise a better system? (I suppose we could add something to the exec: to affirmatively indicate on stderr that the decompressor [or cat, if not using one] exited successfully, and check for that marker in the log file... but that seems quite a dirty hack). Thanks!

2 7

[libvirt] [PATCH 00/27] Refactor QEMU monitor command handling
by Daniel P. Berrange 01 Oct '09

01 Oct '09

In the QEMU driver source code the methods which talk to the QEMU monitor currently all just call qemudMonitorCommand() directly with the raw command string, and then parse the raw reply. In the not too distant future QEMU is introducing a new machine parsable monitor syntax. With the current way the code is structured supporting this new mode will be seriously unpleasant. This large series of patches, moves all the monitor command formatting and parsing code out into a separate source file src/qemu/qemu_monitor_text.c. There is one API in that file for each logical monitor command we wish to issue, accepting (mostly) strongly typed arguments. The exception is the NIC hotplug method which still takes the raw NIC string for now. The main qemu_driver.c file now directly calls the appropriate monitor command APIs, making logic there much cleaner. When we add support for the new QEMU monitor syntax we'll gain another file src/qemu/qemu_monitor_json.c which implements all the same APIs as src/qemu/qemu_monitor_text.c, but using the new JSON syntax instead of raw text strings This patch series is soooooo large, because I did it in many small steps, one command at a time. It is also now much easier to debug the monitor by just setting the env variables LIBVIRT_LOG_OUTPUTS="1:stderr" LIBVIRT_LOG_FILTERS="1:qemu_monitor" And you'll get the command & reply of each monitor interaction printed I've tested basic handling of every new method with the exception of the migration ones, since I don't have a convenient target host when on my laptop. Overall we get a small increase in code size, but huge increase in readability ! Makefile.am | 1 libvirt_private.syms | 1 qemu/qemu_conf.c | 20 qemu/qemu_conf.h | 2 qemu/qemu_driver.c | 1669 +++++--------------------------------------- qemu/qemu_monitor_text.c | 1777 +++++++++++++++++++++++++++++++++++++++++++++++ qemu/qemu_monitor_text.h | 173 ++++ 7 files changed, 2171 insertions(+), 1472 deletions(-) Daniel

4 63

[libvirt] [PATCH] Allows for a <description> tag for domains
by Daniel Veillard 01 Oct '09

01 Oct '09

https://bugzilla.redhat.com/show_bug.cgi?id=523639 feature request which makes sense to me, the simple patch attached seems to be sufficient, one can define and have the description back in the dump. Doesn't try to keep the location of the tag, it always get serialized after <uuid>. The only drawbacks I can think of are: - others XML formats may require the same, but honnestly it's trivial - machine generated description (for example if the history log of a domain gets stored there) could grow a lot and I wonder if we have a hard limit on the size when transmitting xml descriptions Oh and I didn't found a good place to test the feature, i.e. no test seems to parse and reserialize XML it's always about conversions. 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/

4 8

[libvirt] [PATCH] Avoid a libvirtd crash on broken input 523418
by Daniel Veillard 01 Oct '09

01 Oct '09

A simple typo in an XML domain file could lead to a crash, because we called STRPREFIX() on the looked up value without checking it was non-null. Patch is trivial, and should go in but I wonder if we shouldn't make those STR macros safer too like turning #define STRPREFIX(a,b) (strncmp((a),(b),strlen((b))) == 0) into #define STRPREFIX(a,b) ((a) && (b) && (strncmp((a),(b),strlen((b))) == 0)) anyway I think we should apply the patch independently, without it libvirtd crash, with it we get the proper error report: [root@paphio ~]# virsh define RHEL-5.4-64.xml 18:32:21.982: warning : processCallDispatchReply:7570 : Method call error error: Failed to define domain from RHEL-5.4-64.xml error: internal error No <source> 'dev' attribute specified with <interface type='bridge'/> 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/

2 2

[libvirt] [PATCH] Fix USB device re-labelling
by Mark McLoughlin 01 Oct '09

01 Oct '09

A simple misplaced break out of a switch results in: libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./vendor': No such file or directory libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./device': No such file or directory libvir: error : this function is not supported by the hypervisor: Failed to read product/vendor ID for 0000:00:54c. when trying to passthrough a USB host device to qemu. * src/security_selinux.c: fix a switch/break thinko --- src/security/security_selinux.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index bdd9eb2..d08d502 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -492,12 +492,11 @@ SELinuxSetSecurityHostdevLabel(virConnectPtr conn, ret = usbDeviceFileIterate(conn, usb, SELinuxSetSecurityUSBLabel, vm); usbFreeDevice(conn, usb); - - break; } else { /* XXX deal with product/vendor better */ ret = 0; } + break; } case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: { -- 1.6.2.5

2 1