- Devel - libvirt List Archives

[libvirt] CFS Hardlimits and the libvirt cgroups implementation
by Adam Litke 13 Jun '11

13 Jun '11

Hi all. In this post I would like to bring up 3 issues which are tightly related: 1. unwanted behavior when using cfs hardlimits with libvirt, 2. Scaling cputune.share according to the number of vcpus, 3. API proposal for CFS hardlimits support. === 1 === Mark Peloquin (on cc:) has been looking at implementing CFS hard limit support on top of the existing libvirt cgroups implementation and he has run into some unwanted behavior when enabling quotas that seems to be affected by the cgroup hierarchy being used by libvirt. Here are Mark's words on the subject (posted by me while Mark joins this mailing list): ------------------ I've conducted a number of measurements using CFS. The system config is a 2 socket Nehalem system with 64GB ram. Installed is RHEL6.1-snap4. The guest VMs being used have RHEL5.5 - 32bit. I've replaced the kernel with 2.6.39-rc6+ with patches from Paul-V6-upstream-breakout.tar.bz2 for CFS bandwidth. The test config uses 5 VMs of various vcpu and memory sizes. Being used are 2 VMs with 2 vcpus and 4GB of memory, 1 VM with 4vcpus/8GB, another VM with 8vcpus/16GB and finally a VM with 16vcpus/16GB. Thus far the tests have been limited to cpu intensive workloads. Each VM runs a single instance of the workload. The workload is configured to create one thread for each vcpu in the VM. The workload is then capable of completely saturation each vcpu in each VM. CFS was tested using two different topologies. First vcpu cgroups were created under each VM created by libvirt. The vcpu threads from the VM's cgroup/tasks were moved to the tasks list of each vcpu cgroup, one thread to each vcpu cgroup. This tree structure permits setting CFS quota and period per vcpu. Default values for cpu.shares (1024), quota (-1) and period (500000us) was used in each VM cgroup and inherited by the vcpu croup. With these settings the workload generated system cpu utilization (measured in the host) of >99% guest, >0.1 idle, 0.14% user and 0.38 system. Second, using the same topology, the CFS quota in each vcpu's cgroup was set to 250000us allowing each vcpu to consume 50% of a cpu. The cpu workloads was run again. This time the total system cpu utilization was measured at 75% guest, ~24% idle, 0.15% user and 0.40% system. The topology was changed such that a cgroup for each vcpu was created in /cgroup/cpu. The first test used the default/inherited shares and CFS quota and period. The measured system cpu utilization was >99% guest, ~0.5 idle, 0.13 user and 0.38 system, similar to the default settings using vcpu cgroups under libvirt. The next test, like before the topology change, set the vcpu quota values to 250000us or 50% of a cpu. In this case the measured system cpu utilization was ~92% guest, ~7.5% idle, 0.15% user and 0.38% system. We can see that moving the vcpu cgroups from being under libvirt/qemu make a big difference in idle cpu time. Does this suggest a possible problems with libvirt? ------------------ Has anyone else seen this type of behavior when using cgroups with CFS hardlimits? We are working with the kernel community to see if there might be a bug in cgroups itself. === 2 === Something else we are seeing is that libvirt's default setting for cputune.share is 1024 for any domain (regardless of how many vcpus are configured. This ends up hindering performance of really large VMs (with lots of vcpus) as compared to smaller ones since all domains are given equal share. Would folks consider changing the default for 'shares' to be a quantity scaled by the number of vcpus such that bigger domains get to use proportionally more host cpu resource? === 3 === Besides the above issues, I would like to open a discussion on what the libvirt API for enabling cpu hardlimits should look like. Here is what I was thinking: Two additional scheduler parameters (based on the names given in the cgroup fs) will be recognized for qemu domains: 'cfs_period' and 'cfs_quota'. These can use the existing virDomain[Get|Set]SchedulerParameters() API. The Domain XML schema would be updated to permit the following: --- snip --- <cputune> ... <cfs_period>1000000</cfs_period> <cfs_quota>500000</cfs_quota> </cputune> --- snip --- To actuate these configuration settings, we simply apply the values to the appropriate cgroup(s) for the domain. We would prefer that each vcpu be in its own cgroup to ensure equal and fair scheduling across all vcpus running on the system. (We will need to resolve the issues described by Mark in order to figure out where to hang these cgroups). Thanks for sticking with me through this long email. I greatly appreciate your thoughts and comments on these topics. -- Adam Litke IBM Linux Technology Center

4 8

[libvirt] FreeBSD Port update, 0.9.2
by Jason Helfman 13 Jun '11

13 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello All, Here is a link to the update for FreeBSD, if you are interested: http://www.freebsd.org/cgi/query-pr.cgi?pr=157712 This patch is to update the version available in the FreeBSD portstree. Thanks, Jason - -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk3vurQACgkQXpKtZoyM+6VfCgD/XWsjgX0p6iTmvI6CiIyQkzzH bjA7QEdMfF+GOZt5idgA/2/yUlbU/s986u96LlS+0J6iZyFhKaAGfBCxmNgSUBbP =nIJ+ -----END PGP SIGNATURE-----

2 1

[libvirt] [PATCH V2 0/7] support multi function PCI device
by Wen Congyang 13 Jun '11

13 Jun '11

We want to use more than 200+ device. Libvirt does not use multi function PCI device and PCI-to-PCI bridge. So we can not use more than 200+ device if it's a PCI device or it's controller is a PCI device. This patchset adds the support of multi function PCI device. It does not support to hot plug/unplug multi function PCI device. Change log: v1 -> v2: 1. split the patch, and it will be easily to review 2. Auto assign a slot not a function if user does not specify the address. Wen Congyang (7): check whether qemu supports multi function PCI device prevent hot unplugging multi function PCI device the key of hash table should include the function value Reimplement qemuDomainPCIAddressReserveSlot(): reserve all functions in the slot assign the whole slot to the PCI device that has no address the hotplugged PCI device should use the whole slot support multifunction PCI device src/conf/domain_conf.c | 3 + src/qemu/qemu_capabilities.c | 5 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 151 +++++++++++++++++++++++++++++++++++++----- src/qemu/qemu_command.h | 5 ++ src/qemu/qemu_hotplug.c | 76 +++++++++++++++++++-- tests/qemuhelptest.c | 3 +- 7 files changed, 218 insertions(+), 26 deletions(-)

4 23

[libvirt] [PATCH] Fix autostart flag when loading running domains
by Michael Chapman 13 Jun '11

13 Jun '11

Drivers load running persistent and transient domain configs before inactive persistent domain configs, however only the latter would set a domain's autostart flag. This mismatch between the loaded and on-disk state could later cause problems with "virsh autostart": # virsh autostart example error: Failed to mark domain example as autostarted error: Failed to create symlink '/etc/libvirt/qemu/autostart/example.xml to '/etc/libvirt/qemu/example.xml': File exists This patch ensures the autostart flag is set correctly even when the domain is already defined. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=632100 https://bugzilla.redhat.com/show_bug.cgi?id=675319 Signed-off-by: Michael Chapman <mike(a)very.puzzling.org> --- src/conf/domain_conf.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 0d9fef4..5a6ff8b 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -9859,21 +9859,22 @@ static virDomainObjPtr virDomainLoadConfig(virCapsPtr caps, VIR_DOMAIN_XML_INACTIVE))) goto error; + if ((autostartLink = virDomainConfigFile(autostartDir, name)) == NULL) + goto error; + + if ((autostart = virFileLinkPointsTo(autostartLink, configFile)) < 0) + goto error; + /* if the domain is already in our hashtable, we don't need to do * anything further */ if ((dom = virDomainFindByUUID(doms, def->uuid))) { VIR_FREE(configFile); virDomainDefFree(def); + dom->autostart = autostart; return dom; } - if ((autostartLink = virDomainConfigFile(autostartDir, name)) == NULL) - goto error; - - if ((autostart = virFileLinkPointsTo(autostartLink, configFile)) < 0) - goto error; - if (!(dom = virDomainAssignDef(caps, doms, def, false))) goto error; -- 1.7.4.4

2 1

[libvirt] [RFC] OpenVSwitch datapath support (was: Driver development)
by Carlos N. A. Corrêa 13 Jun '11

13 Jun '11

Hi, Cole! As I said, I gone through the list archives and got some insight on how to present my ideas. I tried to use the thread started by Laine Stump ( https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html) as a model. Please, forgive me if my RFC is too verbose: I tried to produce something good. In time: I'm willing to implement this idea as part of my postgraduate work. Index ===== 1. Incorporating Open vSwitch support to libvirt 2. Background 3. Architecture 3.1. Option 1 3.2. Option 2 4. Implementation 1. Incorporating Open vSwitch support to libvirt ================================================ OpenFlow (http://www.openflow.org/) is a technology from the Software Defined Networks (SDN) fame. Switches supporting it export a software interface that allows special programs (Controllers) to dictate how the forwarding of ethernet frames should be done. That decision can not only be based on traditional layer-2 information (physical address 00:01:02:03:04:aa maps to port 1, address 05:06:07:08:09:bb maps to port 2, and so on) but also on information from a mix of network layers, like VLAN tags, IP addresses and/or TCP ports. Controllers may take network flexibility and efficiency to a new level, slicing switches' capacity transparently to run concurrent, isolated networks (FlowVisor, https://openflow.stanford.edu/display/flowvisor/Home) They can also incorporate logic to make the connectivity layer play a greater role in areas like IP routing (RouteFlow, http://sites.google.com/site/routeflow/) network access control (SMAC, http://www.openflowhub.org/display/Snac/SNAC+Home) hosts load-balancing ( http://www.cs.princeton.edu/~jrex/papers/loadwild10.pdf) and live migration (http://conferences.sigcomm.org/sigcomm/2008/papers/p513-ericksonA.pdf) In a very practical view, as libvirt supports a programmatic definition of network nodes, OpenFlow allows for a programmatic definition of traffic forwarding. An IaaS/cloud environment composed of many physical hosts and extensive use of libvirt for hypervisor management could use OpenFlow for virtualized switches management. Even tough its current libvirt enables one to define and instantiate virtual networks, those networks are, basically, Linux kernel bridges which configuration (device IP addresses, naming, connections) is stored into network XML files. Linux bridges doesn't offer a programmatic interface, and depend on not-so-easily-customizable approaches (VLANs, tunnels) to properly isolate traffic. Open vSwitch (or OVS, http://www.openvswitch.org/) is a full software implementation of a network switch. It supports standard management interfaces and protocols (e.g. NetFlow, sFlow) and is being used in a multitude of virtual and cloud-based computing (e.g. XenServer, OpenNebula). Even more, OVS can operate in "OpenFlow-mode". When operating in a traditional ("full switch") fashion, an OVS instance is similar to a Linux bridge - just supporting features that makes them work more like a "real" switch. In this scenario, OVS kernel driver even includes a compatibility layer that allows bridge-utils (and libvirt) to act upon OVS instances just as if they were Linux bridges! When operating in OpenFlow mode, the OVS instance is called a _datapath_. Host interfaces can be bound to and send traffic through it, but forwarding logic is provided by the Controller process. In this scenario, OpenFlow-based solutions could be leveraged to virtual networks. Even more, OpenFlow-based solutions which use virtual facilities (like VMs and OVS) could use libvirt as part of its frameworks! I'm proposing changes to libvirt's network XML format. It would allow for "datapath" elements, and it's attributes would allow libvirt to instantiate a OVS datapath, specifying it's controller address and hardware description, for example. 2. Background ============= To instantiate an OVS datapath (DP), one must call the ovs-openflowd daemon. Some relevant aspects of its syntax are covered below: ------------------------------- 8< ------------------------------- usage: ovs-openflowd [OPTIONS] DATAPATH [CONTROLLER...] Active OpenFlow connection methods: tcp:IP[:PORT] PORT (default: 6633) at remote IP ssl:IP[:PORT] SSL PORT (default: 6633) at remote IP unix:FILE Unix domain socket named FILE Passive OpenFlow connection methods: ptcp:[PORT][:IP] listen to TCP PORT (default: 6633) on IP pssl:[PORT][:IP] listen for SSL on PORT (default: 6633) on IP punix:FILE listen on Unix domain socket FILE OpenFlow options: -d, --datapath-id=ID Use ID as the OpenFlow switch ID (ID must consist of 16 hex digits) --mfr-desc=MFR Identify manufacturer as MFR --hw-desc=HW Identify hardware as HW --sw-desc=SW Identify software as SW Networking options: --out-of-band controller connection is out-of-band Daemon options: --detach run in background as daemon --pidfile[=FILE] create pidfile (default: /usr/local/var/run/openvswitch/ovs-openflowd.pid) ------------------------------- 8< ------------------------------- An execution example can be seen below: # ovs-openflowd --hw-desc=rfovs dp0 tcp:127.0.0.1:6633 --out-of-band --detach This instantiates an OVS datapath with hardware description "rfovs". The datapath name (and Linux virtual interface name) is "dp0". The controller software is running in the same machine as the OVS instance (IP address 127.0.0.1), and can be reached through port 6633/TCP. The connection to the controller must not be done through the datapath itself (out-of-band), and the ovs-openflowd will run as a background daemon. 3. Architecture =============== libvirt documentation available on http://www.libvirt.org/formatnetwork.htmldescribes the following format to network definition: <network>    </network> Based solely in that documentation, the format is somewhat bound to Linux bridges. This is not a problem most of the time, as OVS includes a compatibility module (brcompat_mod) that allows bridge-utils to configure an OVS "full switch" just as if it was a traditional Linux bridge. The syscalls offered also permit libvirt to manage these instances transparently. However, this format doesn't provide sufficient information to configure a OVS datapath. Next, I propose some options of how the libvirt network format could be changed to provide this facility (and, off course, to implement those changes). 3.1. Option 1: network type --------------------------- I saw this in an e-mail from Laine Stump in last April ( https://www.redhat.com/archives/libvir-list/2011-April/msg00640.html) It seems like my preferred ideas about how the change could be accomplished. The network opening element would be extended to include an optional "type" attribute. It could be defined as "bridge" (the default behaviour, for backwards compatibility) or "ovs-datapath" (the case for which I would like to work): <network type="bridge"> (THE DEFAULT) or <network type="ovs-datapath"> As the "General metadata" from the network format is instrumental to libvirt, it would be necessary to a "ovs-datapath" network. As the control layer of an OVS datapath lie outside itself, the "Bridging, naming..." section of the network format would be replaced by the following elements/attributes: <datapath name="" id="" mfrdesc="" hwdesc="" swdesc=""> - Mandatory, this element would allow for datapath and OpenFlow general configuration. - The name attribute would be used to designate the datapath virtual interface. (Mandatory) - The id, mfrdesc, hwdesc and swdesc attributes would be mapped 1:1 to ovs-openflowd parameters presented before. (Optional) <controller protocol="" address="" port="" outofband=""> OR <controller protocol="" path=""> - Protocol. Would be one of "tcp" or "unix", by now. (Mandatory) - Address. Would be an IP address. (Mandatory, if protocol="tcp") - Path. Would be the path to a UNIX socket to which the controller process is listening. (Mandatory, if protocol="unix") - Port. Would be the port to which the controller is listening to. (Optional, default = 6633) - Outofband. If connection to the controller must be done "in" or "out" of band. (Optional, default = "NO"). - The controller element itself would be optional, as OVS includes a "controller discovery" process by default. If specified, however, it's mandatory attributes should be respected. For the sake of a proof-of-concept implementation, this would be the entire (!) scope of the initial change/implementation. After this step, things such as this could be added: - An "ssl" option for the "protocol=" attribute, to allow for SSL-encrypted connections between datapaths and its controllers. - An element to pass SSL connection data (private key, ca cert, etc.) to ovs-openflowd. E.g.: <pki privatekey...> - Elements to control networking operation (e.g. max-idle, max-backoff) and rate-limiting of the datapath. 3.2. Option 2: datapath element ------------------------------- In place of a network type definition, just a new "datapath" element would be added. The network_conf code should test if a "bridge" element is specified in a network definition, and look for a datapath if it can't find one. Addressing data found in a network using the "datapath" element would be ignored. The datapath element here could be overly long, including description, controller and ssl-related attributes - but the format change would be very minimal: <network>  <datapath name="" descriptions="..." controller_data="..."> </network> Other option would be set those properties as sub-elements of <datapath...>, merging this option with the first: <network>  <datapath name="" id="" mfrdesc="" hwdesc="" swdesc=""> <controller protocol="" address="" port="" outofband=""> <pki privatekey...> <networking...> </datapath> </network> Besides being and option, this scenario (in fact, the entire option 2) seems somewhat unclean to me. 4. Implementation ================= 1. I can hack through the network_conf code to make it parse the XML. That's an easy part. 2. I can use the bridge driver as a model + your command execution infrastructure (which is very cool, IMHO) to implement an OVS driver. 3. It's not yet very clear to me where is the code that instantiates each network after it's "def" get parsed. Well, after the first two steps, I think that I would need to just hook the parsing and driver functions together in instantiating/virsh/command-line code. That's all, folks! Best regards, Carlos "Bill" Nilton CISSP, RHCE, ITIL Foundations http://carlosnilton.com.br/ Em 8 de junho de 2011 17:34, Carlos N. A. Corrêa <carlos.nilton(a)gmail.com>escreveu: > Hi, > > I gathered information about that and I'll produce relevant documentation > of my point tonight. > > I'll be glad to do an informed and well structured work. Thanks! > > > Best regards, > Carlos "Bill" Nilton > CISSP, RHCE, ITIL Foundations > http://carlosnilton.com.br/ > > > > Em 8 de junho de 2011 15:41, Cole Robinson <crobinso(a)redhat.com> escreveu: > > On 06/08/2011 07:10 AM, Carlos N. A. Corręa wrote: >> > Hi, >> > >> > I'm interested in developing a new network driver for libvirt (one for >> the >> > definition and management of OpenVSwitch datapaths). >> > >> > I've read some of the code already, and by now my general directions >> are: >> > >> > - Change the function virNetworkDefParseXML in src/conf/network_conf.c >> to >> > define and parse new configuration directives needed by my driver >> > - Use src/network/bridge_driver.c as a template for my new driver, >> replacing >> > code from the services provided by the driver (listed on >> "virNetworkDriver" >> > type) with my own code, for my own net type. >> > >> > Have you any other directions in this matter? Any tips? If it works, >> would >> > be this code of any use to you? >> > >> >> For a starting point I'd recommend proposing your XML changes to the >> list, and describe exactly what the new functionality will enable, and a >> few use cases. Probably best to do this before starting any code so you >> don't head in a wrong direction. >> >> Check the past few month ML archives to see how some other developers >> have proposed RFCs or XML changes. >> >> - Cole >> > >

2 1

[libvirt] [PATCH 00/16] More virCommand conversions and cleanups
by Cole Robinson 11 Jun '11

11 Jun '11

The following series converts all users of several older command wrappers (virRunWithHook, virExecDaemonize, and virExec) to use virCommand. The remaining functionality is then moved out of util.c and into command.c Cole Robinson (16): remote_driver: Convert virExecDaemonize usage to virCommand util: Combine __virExec and virExecWithHook command: Allow setting a NULL hook function storage_backend: Convert virRunWithHook usage to virCommand apparmor: Convert virExec usage to virCommand storage: Convert qemu-img -help parsing to virCommand storage: Covert regex helpers to virCommand storage: iscsi: Convert virExec to virCommand qemu: Convert virExec usage to virCommand openvz: Convert virExec usage to virCommand remote: Convert SSH tunnel to virCommand util: Remove unused virExec wrapper util: Implement virRun as a wrapper around virCommand Move virRun, virExec*, virFork to util/command storage_backend: Fix error reporting with regex helper command: Report stdout/stderr if command fails cfg.mk | 2 +- src/libvirt_private.syms | 8 +- src/lxc/veth.c | 2 +- src/nwfilter/nwfilter_ebiptables_driver.c | 1 + src/openvz/openvz_conf.c | 37 +- src/openvz/openvz_driver.c | 52 ++- src/qemu/qemu_driver.c | 14 +- src/qemu/qemu_process.c | 2 +- src/remote/remote_driver.c | 83 +-- src/security/security_apparmor.c | 70 +--- src/storage/storage_backend.c | 292 ++++-------- src/storage/storage_backend.h | 3 +- src/storage/storage_backend_fs.c | 7 +- src/storage/storage_backend_iscsi.c | 40 +- src/storage/storage_backend_logical.c | 32 +- src/util/command.c | 621 +++++++++++++++++++++++- src/util/command.h | 16 +- src/util/ebtables.c | 2 +- src/util/pci.c | 2 +- src/util/util.c | 764 +---------------------------- src/util/util.h | 44 -- src/vmware/vmware_driver.c | 1 + 22 files changed, 854 insertions(+), 1241 deletions(-) -- 1.7.4.4

4 40

[libvirt] Fwd: cvs commit: ports/devel/libvirt Makefile distinfo pkg-plist ports/devel/libvirt/files patch-docs__apibuild.py patch-src__util__command.c
by Jason Helfman 10 Jun '11

10 Jun '11

libvirt has been updated in the FreeBSD portstree. Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5

1 0

[libvirt] does libvirt get disk->info.alias, when attaching a disk by virDomainAttachDevice?
by 李敬伟 10 Jun '11

10 Jun '11

Hi, I am using libvirt 0.9.1 on CentOS 5.5 64bit , Created a vm :virsh create libvirt.xml Attached a disk ,virsh attach-disk 3 /opt/vms/test.img vdb When getting blosk stats ,virsh domblkstats 3 vdb ,it showed error: Failed to get block stats 3 vdb error: internal error missing disk device alias name for vdb while virsh domblkstat 3 vda, it showed vda rd_req 6667 vda rd_bytes 154084864 vda wr_req 9530 vda wr_bytes 57196544 I guess libvirt does not get disk->info.alias when attaching a disk,so it can not get block status. # virsh version Compiled against library: libvir 0.9.1 Using library: libvir 0.9.1 Using API: QEMU 0.9.1 Running hypervisor: QEMU 0.9.1 # rpm -qa|grep kvm kmod-kvm-83-224.el5.centos.1 kvm-qemu-img-83-224.el5.centos.1 etherboot-zroms-kvm-5.4.4-13.el5.centos kvm-83-224.el5.centos.1 Jingwei Li (lijingwei9060(a)gmail.com<mailto:lijingwei9060@gmail.com> or lijw(a)bingosoft.net<mailto:lijw@bingosoft.net>)

3 2

[libvirt] [PATCH] xenapi: Improve error message on session failure
by Matthew Booth 10 Jun '11

10 Jun '11

XenAPI session login can fail for a number of reasons, but currently no specific reason is displayed to the user, e.g.: virsh -c XenAPI://citrix-xen.example.com/ Enter username for citrix-xen.example.com: root Enter root's password for citrix-xen.example.com: error: authentication failed: (null) error: failed to connect to the hypervisor This patch displays the session error description on failure. --- src/xenapi/xenapi_driver.c | 20 ++++++++++++++++++-- 1 files changed, 18 insertions(+), 2 deletions(-) diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c index 6f64208..3fc35c6 100644 --- a/src/xenapi/xenapi_driver.c +++ b/src/xenapi/xenapi_driver.c @@ -166,7 +166,22 @@ xenapiOpen (virConnectPtr conn, virConnectAuthPtr auth, int flags ATTRIBUTE_UNUS privP->session = xen_session_login_with_password(call_func, privP, username, password, xen_api_latest_version); - if (privP->session != NULL && privP->session->ok) { + if (privP->session == NULL) { + /* From inspection of xen_session_login_with_password in + * libxenserver(Version 5.6.100-1), this appears not to be currently + * possible. The only way for this to be NULL would be on malloc + * failure, except that the code doesn't check for this and would + * segfault before returning. + * + * We don't assume the reason here for a failure in an external library. + */ + xenapiSessionErrorHandler(conn, VIR_ERR_INTERNAL_ERROR, + _("Failed to allocate xen session")); + + goto error; + } + + if (privP->session->ok) { conn->privateData = privP; VIR_FREE(username); @@ -175,7 +190,8 @@ xenapiOpen (virConnectPtr conn, virConnectAuthPtr auth, int flags ATTRIBUTE_UNUS return VIR_DRV_OPEN_SUCCESS; } - xenapiSessionErrorHandler(conn, VIR_ERR_AUTH_FAILED, NULL); + xenapiSessionErrorHandler(conn, VIR_ERR_AUTH_FAILED, + *privP->session->error_description); error: VIR_FREE(username); -- 1.7.4.4

3 2

[libvirt] [PATCH] qemu: Fix one type in the error prompt string
by Osier Yang 10 Jun '11

10 Jun '11

Pushed in trivial rule. --- src/qemu/qemu_command.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index ef2d002..4e68241 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -553,7 +553,7 @@ qemuAssignDeviceHostdevAlias(virDomainDefPtr def, virDomainHostdevDefPtr hostdev int thisidx; if ((thisidx = qemuDomainDeviceAliasIndex(&def->hostdevs[i]->info, "hostdev")) < 0) { qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Unable to determine device index for hostdevwork device")); + _("Unable to determine device index for hostdev device")); return -1; } if (thisidx >= idx) -- 1.7.4

1 0