- Devel - libvirt List Archives

[libvirt] Connection using Java
by Felipe Oliveira Gutierrez 16 Oct '12

16 Oct '12

Hi, I am using java to connect to the xen, but my class is throwing a exception. Does anyone know what is happening? public class TestConnection { public static void main(String[] args) { Connect conn = null; try { conn = new Connect("xen+ssh://root@192.XXX.XXX.XX/", true); libvir: RPC error : End of file while reading data: nc: invalid option -- 'U' nc -h for help: Input/output error exception caught:org.libvirt.LibvirtException: End of file while reading data: nc: invalid option -- 'U' nc -h for help: Input/output error level:VIR_ERR_ERROR code:VIR_ERR_SYSTEM_ERROR domain:VIR_FROM_RPC hasConn:false hasDom:false hasNet:false message:End of file while reading data: nc: invalid option -- 'U' nc -h for help: Input/output error str1:%s str2:End of file while reading data: nc: invalid option -- 'U' nc -h for help: Input/output error str3:null int1:-1 int2:-1 Thanks, Felipe -- *-- Felipe Oliveira Gutierrez* *-- **lipe.82(a)gmail.com* <lipe.82(a)gmail.com> *-- https://sites.google.com/site/lipe82/Home/diaadia*

3 3

[libvirt] CPU utilization between physical CPU and virtual CPU in KVM
by Dennis Chen 16 Oct '12

16 Oct '12

Hi All, I am confused by the following observed scenario: In my 4-CPU (KVM supported, 2 core with 2 thread for each) host machine box, I create only one VM with 3-vCPU through virsh/libvirt tools and also I pin this VM process to the physical processor 3. I guess the CPU utilization for the processor 3 will not exceed 100%, then I create 3 process (dead loop-- while(1);) and bind each of them to vCPU[0-2] respectively, through the "top -c" command in VM environment, I can see the CPU utilization for each of the vCPU is about 100%, but interesting, I found that the CPU utilization of processor 3 in the host machine is about 300% with "toc -c" command. why does a single process bound to a CPU can get ~300% cpu bandwidth in this case, does the kernel scheduler dispatch the idle cycle capacity of the CPUs to the virtual CPU of the VM, other word, the scheduler knows the vCPU info in the VM process? For the same case, if I create another 4 new dead-loop processes and bind them to the physical CPU[0-3] equally, then I find the vCPU0/1 in VM will not be 100%, eg. 32%, (I think the scheduler in the guest OS doesn't know it's running in a virtual environment, so the utilization of the vCPU will not change to adapt to the physical processor utilization, but it did, why? -org-gnu

1 1

[libvirt] necessary to limit container's network bandwidth when use physical nic in container?
by Gao feng 16 Oct '12

16 Oct '12

we can use tc to limit container's network bandwidth when the container uses veth device. because one of the veth devices will be seen in the host.so we can set tc rules on this device on the host. I want to know if it's necessary to limit container's network bandwidth when the container uses a physical nic device. because this nic device is only used by this container. And if this is necessary,Be there any good idea? Thanks!

3 4

[libvirt] Proposed libguestfs API for implementing libvirt virConnectOpenAuth
by Richard W.M. Jones 15 Oct '12

15 Oct '12

As in the example code below. static void do_auth (guestfs_h *g, void *opaque, uint64_t event, int event_handle, int flags, const char *buf, size_t buf_len, const uint64_t *array, size_t array_len) { char **creds; size_t i; char *prompt; char *reply; size_t replylen; // buf will be the libvirt URI. It is always \0-terminated so // buf_len can be ignored in this case. printf ("Authentication required for libvirt connection '%s'\n", buf); // Ask libguestfs what credentials libvirt is demanding. creds = guestfs_get_libvirt_requested_credentials (g); // Now ask the user for answers. for (i = 0; creds[i] != NULL; ++i) { if (strcmp (creds[i], "authname") == 0 || strcmp (creds[i], "passphrase") == 0) { prompt = guestfs_get_libvirt_requested_credential_prompt (g, i); printf ("%s: ", prompt); free (prompt); // ... // Input from user is in 'reply', length 'replylen' (bytes). guestfs_set_libvirt_requested_credential (g, i, reply, replylen); } free (creds[i]); } free (creds); // On return from this function (libguestfs event), the libvirt // event returns too. } // ... { guestfs_h *g; char *creds[] = { "authname", "passphrase", NULL }; g = guestfs_create (); guestfs_set_libvirt_supported_credentials (g, creds); guestfs_set_event_callback (g, do_auth, GUESTFS_EVENT_LIBVIRT_AUTH, 0, NULL); // An example of a function that would open a libvirt connection: guestfs_add_domain (g, "dom", GUESTFS_ADD_DOMAIN_LIBVIRTURI, "qemu:///system", -1); } ---------------------------------------------------------------------- By the way, some of the virt tools can open multiple connections to libvirt, and it is architecturally hard to change this: https://www.redhat.com/archives/libguestfs/2012-October/msg00065.html Does libvirt (or policy kit?) provide any mechanism for caching these credentials within the same process, so that we don't have to provide the same creds back to libvirt for multiple connections? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

3 5

[libvirt] [PATCH V1] qemu-attach: Calculate index value if not already specified
by Supriya Kannery 15 Oct '12

15 Oct '12

virsh qemu-attach fails if user has not specified values for index/unit/bus for a drive in qemu commandline. Set default values instead of returning error. Signed-off-by: Supriya Kannery <supriyak(a)linux.vnet.ibm.com> --- src/qemu/qemu_command.c | 10 ---------- 1 files changed, 0 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 09f412e..8ba67a1 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -7130,16 +7130,6 @@ qemuParseCommandLineDisk(virCapsPtr caps, def->bus == VIR_DOMAIN_DISK_BUS_VIRTIO) idx = nvirtiodisk; - if (idx == -1 && - unitid == -1 && - busid == -1) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("missing index/unit/bus parameter in drive '%s'"), val); - virDomainDiskDefFree(def); - def = NULL; - goto cleanup; - } - if (idx == -1) { if (unitid == -1) unitid = 0;

1 0

[libvirt] [PATCH] (failed) virConnectOpenAuth: Add VIR_CONNECT_NO_DEFAULT_ERROR_HANDLER flag.
by Richard W.M. Jones 15 Oct '12

15 Oct '12

Well, it was a good idea, but the patch doesn't work. Apparently along their open paths, drivers don't set errors in the newly created handle, but in the global handler instead (hence the errors still get printed to stderr). How much I hate virterror ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

3 4

[libvirt] [PATCH] maint: drop spurious semicolons
by Eric Blake 15 Oct '12

15 Oct '12

Detected with: git grep ';;$' -- '**/*.[ch]' * src/network/bridge_driver.c (networkRadvdConfContents): Fix harmless typo. * src/phyp/phyp_driver.c (phypUUIDTable_Pull): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDriveDel): Likewise. --- Pushing under the trivial rule. src/network/bridge_driver.c | 2 +- src/phyp/phyp_driver.c | 2 +- src/qemu/qemu_monitor_json.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 0c4b0b0..5578373 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -981,7 +981,7 @@ networkRestartDhcpDaemon(virNetworkObjPtr network) static int networkRadvdConfContents(virNetworkObjPtr network, char **configstr) { - virBuffer configbuf = VIR_BUFFER_INITIALIZER;; + virBuffer configbuf = VIR_BUFFER_INITIALIZER; int ret = -1, ii; virNetworkIpDefPtr ipdef; bool v6present = false; diff --git a/src/phyp/phyp_driver.c b/src/phyp/phyp_driver.c index a1724ca..a3885a7 100644 --- a/src/phyp/phyp_driver.c +++ b/src/phyp/phyp_driver.c @@ -736,7 +736,7 @@ phypUUIDTable_Pull(virConnectPtr conn) if (!channel) { if (libssh2_session_last_errno(session) != LIBSSH2_ERROR_EAGAIN) { - goto err;; + goto err; } else { waitsocket(sock, session); } diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index c35948e..2daf8ea 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -3068,7 +3068,7 @@ int qemuMonitorJSONDriveDel(qemuMonitorPtr mon, _("deleting disk is not supported. " "This may leak data if disk is reassigned")); ret = 1; - virResetLastError();; + virResetLastError(); } } } else if (qemuMonitorJSONHasError(reply, "DeviceNotFound")) { -- 1.7.11.7

1 0

[libvirt] [PATCH 3/3] Take the forwarding family into account
by Benjamin Cama 15 Oct '12

15 Oct '12

Only add iptables rules for this family, and also only check for forwarding for this family. --- src/network/bridge_driver.c | 27 +++++++++++++++++++++------ 1 files changed, 21 insertions(+), 6 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index e3e8dc2..6bd4217 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -1788,7 +1788,9 @@ networkAddIptablesRules(struct network_driver *driver, return -1; for (ii = 0; - (ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii)); + (ipdef = virNetworkDefGetIpByIndex(network->def, + network->def->forwardFamily, + ii)); ii++) { /* Add address-specific iptables rules */ if (networkAddIpSpecificIptablesRules(driver, network, ipdef) < 0) { @@ -1803,7 +1805,9 @@ err: * added for previous IP addresses. */ while ((--ii >= 0) && - (ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii))) { + (ipdef = virNetworkDefGetIpByIndex(network->def, + network->def->forwardFamily, + ii))) { networkRemoveIpSpecificIptablesRules(driver, network, ipdef); } networkRemoveGeneralIptablesRules(driver, network); @@ -1819,7 +1823,9 @@ networkRemoveIptablesRules(struct network_driver *driver, virNetworkIpDefPtr ipdef; for (ii = 0; - (ipdef = virNetworkDefGetIpByIndex(network->def, AF_UNSPEC, ii)); + (ipdef = virNetworkDefGetIpByIndex(network->def, + network->def->forwardFamily, + ii)); ii++) { networkRemoveIpSpecificIptablesRules(driver, network, ipdef); } @@ -2173,9 +2179,18 @@ networkStartNetworkVirtual(struct network_driver *driver, goto err2; /* If forwardType != NONE, check for IP forwarding */ - if (network->def->forwardType != VIR_NETWORK_FORWARD_NONE && - networkCheckIpForwarding(v4present, v6present) < 0) { - goto err3; + if (network->def->forwardType != VIR_NETWORK_FORWARD_NONE) { + if (network->def->forwardFamily) { + /* if forwardFamily is set, we have at least a corresponding + * family's address + */ + if (networkCheckIpForwarding(network->def->forwardFamily == AF_INET, + network->def->forwardFamily == AF_INET6) < 0) + goto err3; + } else { + if (networkCheckIpForwarding(v4present, v6present) < 0) + goto err3; + } } -- 1.7.2.5

2 1

[libvirt] [PATCH 0/8] RFC New API to retrieve host node CPU map
by Viktor Mihajlovski 15 Oct '12

15 Oct '12

Rationale: In order to use the APIs listed below it is necessary for a client to know the maximum number of node CPUs which is passed via the maplen argument. virDomainGetEmulatorPinInfo virDomainGetVcpuPinInfo virDomainGetVcpus virDomainPinEmulator virDomainPinVcpu virDomainPinVcpuFlags The current approach uses virNodeGetInfo to determine the maximum CPU number. This can lead to incorrect results if not all node CPUs are online. The maximum CPU number should always be the number of CPUs present on the host, regardless of their online/offline state. The following example illustrates the issue: Host has 3 logical CPUs, 1 socket, 3 cores, 1 thread. Guest has 1 virtual CPU and is started while all 3 host CPUs are online. $ virsh vcpuinfo guest VCPU: 0 CPU: 0 State: running CPU time: 35.4s CPU Affinity: yyy $ echo 0 > /sys/devices/system/cpu/cpu1/online $ virsh vcpuinfo guest VCPU: 0 CPU: 0 State: running CPU time: 35.5s CPU Affinity: y- The correct display for CPU affinity would have been y-y, as the guest continues to use CPUs 0 and 2. This is not a display problem only, because it is also not possible to explicitly pin the virtual CPU to host CPUs 0 and 2, due to the truncated CPU mask. PROPOSAL: To help solve the issue above I suggest a new public API: int virNodeGetCPUMapFlags(virConnectPtr conn, unsigned char **cpumap, unsigned int *online, unsigned int flags); The function will return the number of CPUs present on the host or -1 on failure; If cpumap is non-NULL virNodeGetCPUMapFlags will allocate an array containing a bit map representation of the online CPUs. It's the callers responsibility to deallocate cpumap using free(). If online is non-NULL, the variable pointed to will contain the number of online host node CPUs. The variable flags has been added to support future extensions and must be set to 0. Clients can use virNodeGetCPUMapFlags to properly determine the maximum number of node CPUs and their online/offline state. Remarks: This series implements the QEMU and test drivers. This series doesn't introduce changes to the existing vcpu pinning, which I would submit as a succeeding patch set. No python binding yet. Viktor Mihajlovski (8): virNodeGetCPUMapFlags: Define public API. virNodeGetCPUMapFlags: Define driver API. virNodeGetCPUMapFlags: Implement public API. virNodeGetCPUMapFlags: Implement wire protocol. libvirt.h.in: Add new cpumap macro VIR_CPU_USED virNodeGetCPUMapFlags: Implement virsh support. virNodeGetCPUMapFlags: Implement support function in nodeinfo virNodeGetCPUMapFlags: Implement driver support daemon/remote.c | 44 +++++++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 28 ++++++++++++++++++--- python/generator.py | 1 + src/driver.h | 7 +++++ src/libvirt.c | 56 ++++++++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 +++ src/nodeinfo.c | 49 ++++++++++++++++++++++++++++++++++++ src/nodeinfo.h | 6 ++++ src/qemu/qemu_driver.c | 1 + src/remote/remote_driver.c | 49 ++++++++++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 13 +++++++++- src/remote_protocol-structs | 12 +++++++++ src/test/test_driver.c | 30 ++++++++++++++++++++++ tools/virsh-host.c | 41 ++++++++++++++++++++++++++++++ tools/virsh.pod | 5 +++ 16 files changed, 343 insertions(+), 5 deletions(-)

1 8

[libvirt] [PATCH] RFC: Clarify the relationship between <vcpu>, <vcpupin>, and <emulatorpin>
by Osier Yang 15 Oct '12

15 Oct '12

These 3 elements conflicts with each other in either the doc or the underlying codes are. This is to propse a solution. Before writing any codes, I want to see if the principle is correct, any advise is welcomed. Current problems: Problem 1: The doc shouldn't simply say "These settings are superseded by CPU tuning. " for element <vcpu>. As except the tuning, <vcpu> allows to specify the current, maxmum vcpu number. Apart from that, <vcpu> also allows to specify the placement as "auto", which binds the domain process to the advisory nodeset from numad. Problem 2: Doc for <vcpu> says its "cpuset" specify the physical CPUs that the vcpus can be pinned. But it's not the truth, as actually it only pin domain process to the specified physical CPUs. So either it's a document bug, or code bug. Problem 3: Doc for <vcpupin> says it supersed "cpuset" of <vcpu>, it's not quite correct, as each <vcpupin> specify the pinning policy only for one vcpu. How about the ones which doesn't have <vcpupin> specified? it says the vcpu will be pinned to all available physical CPUs, but what's the meaning of attribute "cpuset" of <vcpu> then? Problem 4: Doc for <emulatorpin> says it pin the emulator threads (domain process in other context, perhaps another follow up patch to cleanup the inconsistency is needed) to the physical CPUs specified its attribute "cpuset". Which conflicts with <vcpu>'s "cpuset". And actually in the underlying codes, it set the affinity for domain process twice if both "cpuset" for <vcpu> and <emulatorpin> are specified, and <emulatorpin>'s pinning will override <vcpu>'s. Problem 5: When "placement" of <vcpu> is "auto" (I.e. uses numad to get the advisory nodeset to which the domain process is pinned to), it will also be overridden by <emulatorpin>, This patch is trying to sort out the conflicts or bugs by: 1) Don't say <vcpu> is superseded by <cputune> 2) Keep the semanteme for "cpuset" of <vcpu> (I.e. Still says it specify the physical CPUs the virtual CPUs). But modifying it to mention it also set the pinning policy for domain process, and the CPU placement of domain process specified by "cpuset" of <vcpu> will be ingored if <emulatorpin> specified, and similary, the CPU placement of vcpu thread will be ignored if it has <vcpupin> specified, for vcpu which doesn't have <vcpupin> specified, it inherits "cpuset" of <vcpu>. 3) Don't say <vcpu> is supersed by <vcpupin>. If neither <vcpupin> nor "cpuset" of <vcpu> is specified, the vcpu will be pinned to all available pCPUs. 4) If neither <emulatorpin> nor "cpuset" of <vcpu> is specified, the domain process (emulator threads in the context) will be pinned to all available pCPUs. 5) If "placement" of <vcpu> is "auto", <emulatorpin> is not allowed. 6) hotplugged vcpus will also inherit "cpuset" of <vcpu> Codes changes above document changes will cause: 1) Inherit def->cpumask for each vcpu which doesn't have <vcpupin> specified, during parsing. 2) ping the vcpu which doesn't have <vcpupin> specified to def->cpumask either by cgroup for sched_setaffinity(2), which is actually done by 1). 3) Error out if "placement" == "auto", and <emulatorpin> is specified. Otherwise, <emulatorpin> is honored, and "cpuset" of <cpuset> is ignored. 4) Setup cgroup for each hotplugged vcpu, and setup the pinning policy by either cgroup or sched_setaffinity(2). 5) Remove cgroup and <vcpupin> for each hot unplugged vcpu. --- docs/formatdomain.html.in | 42 +++++++++++++++++++++++++++--------------- 1 files changed, 27 insertions(+), 15 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index d664e7e..1ae8cf4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -357,8 +357,18 @@ the maximum supported by the hypervisor. Since 0.4.4, this element can contain an optional <code>cpuset</code> attribute, which is a comma-separated - list of physical CPU numbers that virtual CPUs can be pinned - to. Each element in that list is either a single CPU number, + list of physical CPU numbers that domain process and virtual CPUs + can be pinned to by default. (NB: The pinning policy of domain + process and virtual CPUs can be specified separately by + <code>cputune</code>. If attribute <code>emulatorpin</code> + of <code>cputune</code> is specified, <code>cpuset</code> + specified by <code>vcpu</code> here will be ingored; Similarly, + For virtual CPUs which has <code>vcpupin</code> specified, + <code>cpuset</code> specified by <code>cpuset</code> here + will be ignored; For virtual CPUs which doesn't have + <code>vcpupin</code> specified, it will be pinned to the physical + CPUs specified by <code>cpuset</code> here). + Each element in that list is either a single CPU number, a range of CPU numbers, or a caret followed by a CPU number to be excluded from a previous range. Since 0.8.5, the optional attribute <code>current</code> can @@ -374,8 +384,7 @@ if it's specified. If both <code>cpuset</code> and <code>placement</code> are not specified, or if <code>placement</code> is "static", but no <code>cpuset</code> is specified, the domain process will be pinned to - all the available physical CPUs. These settings are superseded - by <a href="#elementsCPUTuning">CPU tuning</a>. + all the available physical CPUs. </dd> </dl> @@ -411,23 +420,26 @@ <dt><code>vcpupin</code></dt> <dd> The optional <code>vcpupin</code> element specifies which of host's - physical CPUs the domain VCPU will be pinned to. This setting supersedes - previous VCPU placement specified in <a href="#elementsCPUAllocation">CPU - Allocation</a> using <code>vcpu</code> element. If this is omitted, - each VCPU is pinned to all the physical CPUs by default. It contains two - required attributes, the attribute <code>vcpu</code> specifies vcpu id, - and the attribute <code>cpuset</code> is same as - attribute <code>cpuset</code> - of element <code>vcpu</code>. (NB: Only qemu driver support) + physical CPUs the domain VCPU will be pinned to. If this is omitted, + and attribute <code>cpuset</code> of element <code>vcpu</code> is + not specified, the vCPU is pinned to all the physical CPUs by default. + It contains two required attributes, the attribute <code>vcpu</code> + specifies vcpu id, and the attribute <code>cpuset</code> is same as + attribute <code>cpuset</code> of element <code>vcpu</code>. + (NB: Only qemu driver support) Since 0.9.0 </dd> <dt><code>emulatorpin</code></dt> <dd> The optional <code>emulatorpin</code> element specifies which of host physical CPUs the "emulator", a subset of a domain not including vcpu, - will be pinned to. If this is omitted, "emulator" is pinned to all - the physical CPUs by default. It contains one required attribute - <code>cpuset</code> specifying which physical CPUs to pin to. + will be pinned to. If this is omitted, and attribute + <code>cpuset</code> of element <code>vcpu</code> is not specified, + "emulator" is pinned to all the physical CPUs by default. It contains + one required attribute <code>cpuset</code> specifying which physical + CPUs to pin to. NB, <code>emulatorpin</code> is not allowed if + attribute <code>placement</code> of element <code>vcpu</code> is + "auto". </dd> <dt><code>shares</code></dt> <dd> -- 1.7.7.6

4 4