1. 31 7月, 2013 4 次提交
  2. 30 7月, 2013 4 次提交
  3. 29 7月, 2013 10 次提交
    • E
      build: fix another virdbus issue on mingw · 9d62472f
      Eric Blake 提交于
      Depending on the set of mingw packages installed, it is possible
      that other .c files hit the mingw header pollution from the
      virdbus.h file.
      
      In file included from ../../src/rpc/virnetserver.c:39:0:
      ../../src/util/virdbus.h:41:35: error: expected ';', ',' or ')' before 'struct'
                             const char *interface,
                                         ^
      
      * src/util/virdbus.h (virDBusCallMethod): Match .c file change.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      9d62472f
    • E
      build: fix virutil build on mingw · cd725c7a
      Eric Blake 提交于
      On platforms without decent group support, the build failed:
      
      Cannot export virGetGroupList: symbol not defined
      ./.libs/libvirt_security_manager.a(libvirt_security_manager_la-security_dac.o): In function `virSecurityDACPreFork':
      /home/eblake/libvirt-tmp/build/src/../../src/security/security_dac.c:248: undefined reference to `virGetGroupList'
      collect2: error: ld returned 1 exit status
      
      * src/util/virutil.c (virGetGroupList): Provide dummy implementation.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      cd725c7a
    • E
      build: fix virthread build on mingw · 4c1c336c
      Eric Blake 提交于
      Our recent conversion to make VIR_ALLOC report oom wasn't
      tested on mingw:
      
      In file included from ../../src/util/virthread.c:29:0:
      ../../src/util/virthreadwin32.c: In function 'virCondWait':
      ../../src/util/virthreadwin32.c:166:81: error: 'VIR_FROM_THIS' undeclared (first use in this function)
           if (VIR_REALLOC_N(c->waiters, c->nwaiters + 1) < 0) {
                                                                                       ^
      
      * src/util/virthreadwin32.c (VIR_FROM_THIS): Define.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      4c1c336c
    • E
      build: fix virdbus build on mingw · 61fac39e
      Eric Blake 提交于
      Mingw headers pollute the namespace.
      
        CC       libvirt_util_la-virdbus.lo
      ../../src/util/virdbus.c:1102:35: error: expected ';', ',' or ')' before 'struct'
                             const char *interface,
                                         ^
      
      * src/util/virdbus.c (virDBusCallMethod): Avoid 'interface'.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      61fac39e
    • E
      build: fix vircgroup build on mingw · a2d0c3f5
      Eric Blake 提交于
      The previous patch was incomplete.
      
        CC       libvirt_util_la-vircgroup.lo
      ../../src/util/vircgroup.c:70:12: error: 'virCgroupPartitionEscape' declared 'static' but never defined [-Werror=unused-function]
       static int virCgroupPartitionEscape(char **path);
                  ^
      
      * src/util/vircgroup.c (virCgroupPartitionEscape): Move forward
      declaration inside conditional.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      a2d0c3f5
    • D
      Conditionalize build of virCgroupValidateMachineGroup · 7cf81fa1
      Daniel P. Berrange 提交于
      The virCgroupValidateMachineGroup method calls some functions
      which are only conditionally compiled, thus it too must be
      made conditional. This fixes the build on non-Linux hosts.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      7cf81fa1
    • E
      build: fix VPATH 'make check' · 7df291a6
      Eric Blake 提交于
      A VPATH build 'make check' was failing with:
      
        GEN      check-driverimpls
      Can't open ../../src/../../src/lxc/lxc_monitor_protocol.h: No such file or directory at ../../src/check-driverimpls.pl line 29, <> line 27153.
      Can't open ../../src/../../src/lxc/lxc_monitor_protocol.c: No such file or directory at ../../src/check-driverimpls.pl line 29, <> line 27153.
      ...
        GEN      check-aclrules
      cannot read ../../src/../../src/remote/remote_protocol.x at ../../src/check-aclrules.pl line 128.
      
      because $(srcdir) was being prepended to file names that already
      included it.
      
      * src/Makefile.am (check-driverimpls): Don't add srcdir twice.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      7df291a6
    • D
      Fix probing of legacy Xen driver to not leave URI set · b7caae92
      Daniel P. Berrange 提交于
      When the legacy Xen driver probes with a NULL URI, and
      finds itself running on Xen, it will set conn->uri. A
      little bit later though it checks to see if libxl support
      exists, and if so declines the driver. This leaves the
      conn->uri set to 'xen:///', so if libxl also declines
      it, it prevents probing of the QEMU driver.
      
      Once a driver has set the conn->uri, it must *never*
      decline an open request. So we must move the libxl
      check earlier
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      b7caae92
    • L
      cpu: Fix one compile error for PPC. · 18398cfd
      Li Zhang 提交于
      CPU data structure is refined, which causes one compile error for PPC.
      Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
      18398cfd
    • G
      caps: use -device for primary video when qemu >=1.6 · e3f2686b
      Guannan Ren 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=981094
      The commit 0ad9025e introduce qemu flag QEMU_CAPS_DEVICE_VIDEO_PRIMARY
      for using -device VGA, -device cirrus-vga, -device vmware-svga and
      -device qxl-vga. In use, for -device qxl-vga, mouse doesn't display
      in guest window like the desciption in above bug.
      This patch try to use -device for primary video when qemu >=1.6 which
      contains the bug fix patch
      e3f2686b
  4. 27 7月, 2013 2 次提交
    • E
      build: avoid uninitialized use warning · c86c3c32
      Eric Blake 提交于
      Otherwise, with new enough gcc compiling at -O2, the build fails with:
      ../../src/conf/domain_conf.c: In function ‘virDomainDeviceDefPostParse’:
      ../../src/conf/domain_conf.c:2821:29: error: ‘cnt’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
                   for (i = 0; i < *cnt; i++) {
                                   ^
      ../../src/conf/domain_conf.c:2795:20: note: ‘cnt’ was declared here
               size_t i, *cnt;
                          ^
      ../../src/conf/domain_conf.c:2794:30: error: ‘arrPtr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
               virDomainChrDefPtr **arrPtr;
                                    ^
      
      * src/conf/domain_conf.c (virDomainChrGetDomainPtrs): Always
      assign into output parameters.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      c86c3c32
    • D
      Set default partition in libvirtd instead of libvirt_lxc · 35fe8d97
      Daniel P. Berrange 提交于
      By setting the default partition in libvirt_lxc it is not
      visible when querying the live XML. Move setting of the
      default partition into libvirtd virLXCProcessStart
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      35fe8d97
  5. 26 7月, 2013 12 次提交
  6. 25 7月, 2013 5 次提交
  7. 24 7月, 2013 3 次提交
    • M
      virLXCMonitorClose: Unlock domain while closing monitor · 4e5f0dd2
      Michal Privoznik 提交于
      There's a race in lxc driver causing a deadlock. If a domain is
      destroyed immediately after started, the deadlock can occur. When domain
      is started, the even loop tries to connect to the monitor. If the
      connecting succeeds, virLXCProcessMonitorInitNotify() is called with
      @mon->client locked. The first thing that callee does, is
      virObjectLock(vm). So the order of locking is: 1) @mon->client, 2) @vm.
      
      However, if there's another thread executing virDomainDestroy on the
      very same domain, the first thing done here is locking the @vm. Then,
      the corresponding libvirt_lxc process is killed and monitor is closed
      via calling virLXCMonitorClose(). This callee tries to lock @mon->client
      too. So the order is reversed to the first case. This situation results
      in deadlock and unresponsive libvirtd (since the eventloop is involved).
      
      The proper solution is to unlock the @vm in virLXCMonitorClose prior
      entering virNetClientClose(). See the backtrace as follows:
      
      Thread 25 (Thread 0x7f1b7c9b8700 (LWP 16312)):
      0  0x00007f1b80539714 in __lll_lock_wait () from /lib64/libpthread.so.0
      1  0x00007f1b8053516c in _L_lock_516 () from /lib64/libpthread.so.0
      2  0x00007f1b80534fbb in pthread_mutex_lock () from /lib64/libpthread.so.0
      3  0x00007f1b82a637cf in virMutexLock (m=0x7f1b3c0038d0) at util/virthreadpthread.c:85
      4  0x00007f1b82a4ccf2 in virObjectLock (anyobj=0x7f1b3c0038c0) at util/virobject.c:320
      5  0x00007f1b82b861f6 in virNetClientCloseInternal (client=0x7f1b3c0038c0, reason=3) at rpc/virnetclient.c:696
      6  0x00007f1b82b862f5 in virNetClientClose (client=0x7f1b3c0038c0) at rpc/virnetclient.c:721
      7  0x00007f1b6ee12500 in virLXCMonitorClose (mon=0x7f1b3c007210) at lxc/lxc_monitor.c:216
      8  0x00007f1b6ee129f0 in virLXCProcessCleanup (driver=0x7f1b68100240, vm=0x7f1b680ceb70, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:174
      9  0x00007f1b6ee14106 in virLXCProcessStop (driver=0x7f1b68100240, vm=0x7f1b680ceb70, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:710
      10 0x00007f1b6ee1aa36 in lxcDomainDestroyFlags (dom=0x7f1b5c002560, flags=0) at lxc/lxc_driver.c:1291
      11 0x00007f1b6ee1ab1a in lxcDomainDestroy (dom=0x7f1b5c002560) at lxc/lxc_driver.c:1321
      12 0x00007f1b82b05be5 in virDomainDestroy (domain=0x7f1b5c002560) at libvirt.c:2303
      13 0x00007f1b835a7e85 in remoteDispatchDomainDestroy (server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0, rerr=0x7f1b7c9b7c30, args=0x7f1b5c004a50) at remote_dispatch.h:3143
      14 0x00007f1b835a7d78 in remoteDispatchDomainDestroyHelper (server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0, rerr=0x7f1b7c9b7c30, args=0x7f1b5c004a50, ret=0x7f1b5c0029e0) at remote_dispatch.h:3121
      15 0x00007f1b82b93704 in virNetServerProgramDispatchCall (prog=0x7f1b8573af90, server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0) at rpc/virnetserverprogram.c:435
      16 0x00007f1b82b93263 in virNetServerProgramDispatch (prog=0x7f1b8573af90, server=0x7f1b857419d0, client=0x7f1b8574ae40, msg=0x7f1b8574acf0) at rpc/virnetserverprogram.c:305
      17 0x00007f1b82b8c0f6 in virNetServerProcessMsg (srv=0x7f1b857419d0, client=0x7f1b8574ae40, prog=0x7f1b8573af90, msg=0x7f1b8574acf0) at rpc/virnetserver.c:163
      18 0x00007f1b82b8c1da in virNetServerHandleJob (jobOpaque=0x7f1b8574dca0, opaque=0x7f1b857419d0) at rpc/virnetserver.c:184
      19 0x00007f1b82a64158 in virThreadPoolWorker (opaque=0x7f1b8573cb10) at util/virthreadpool.c:144
      20 0x00007f1b82a63ae5 in virThreadHelper (data=0x7f1b8574b9f0) at util/virthreadpthread.c:161
      21 0x00007f1b80532f4a in start_thread () from /lib64/libpthread.so.0
      22 0x00007f1b7fc4f20d in clone () from /lib64/libc.so.6
      
      Thread 1 (Thread 0x7f1b83546740 (LWP 16297)):
      0  0x00007f1b80539714 in __lll_lock_wait () from /lib64/libpthread.so.0
      1  0x00007f1b8053516c in _L_lock_516 () from /lib64/libpthread.so.0
      2  0x00007f1b80534fbb in pthread_mutex_lock () from /lib64/libpthread.so.0
      3  0x00007f1b82a637cf in virMutexLock (m=0x7f1b680ceb80) at util/virthreadpthread.c:85
      4  0x00007f1b82a4ccf2 in virObjectLock (anyobj=0x7f1b680ceb70) at util/virobject.c:320
      5  0x00007f1b6ee13bd7 in virLXCProcessMonitorInitNotify (mon=0x7f1b3c007210, initpid=4832, vm=0x7f1b680ceb70) at lxc/lxc_process.c:601
      6  0x00007f1b6ee11fd3 in virLXCMonitorHandleEventInit (prog=0x7f1b3c001f10, client=0x7f1b3c0038c0, evdata=0x7f1b8574a7d0, opaque=0x7f1b3c007210) at lxc/lxc_monitor.c:109
      7  0x00007f1b82b8a196 in virNetClientProgramDispatch (prog=0x7f1b3c001f10, client=0x7f1b3c0038c0, msg=0x7f1b3c003928) at rpc/virnetclientprogram.c:259
      8  0x00007f1b82b87030 in virNetClientCallDispatchMessage (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1019
      9  0x00007f1b82b876bb in virNetClientCallDispatch (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1140
      10 0x00007f1b82b87d41 in virNetClientIOHandleInput (client=0x7f1b3c0038c0) at rpc/virnetclient.c:1312
      11 0x00007f1b82b88f51 in virNetClientIncomingEvent (sock=0x7f1b3c0044e0, events=1, opaque=0x7f1b3c0038c0) at rpc/virnetclient.c:1832
      12 0x00007f1b82b9e1c8 in virNetSocketEventHandle (watch=3321, fd=54, events=1, opaque=0x7f1b3c0044e0) at rpc/virnetsocket.c:1695
      13 0x00007f1b82a272cf in virEventPollDispatchHandles (nfds=21, fds=0x7f1b8574ded0) at util/vireventpoll.c:498
      14 0x00007f1b82a27af2 in virEventPollRunOnce () at util/vireventpoll.c:645
      15 0x00007f1b82a25a61 in virEventRunDefaultImpl () at util/virevent.c:273
      16 0x00007f1b82b8e97e in virNetServerRun (srv=0x7f1b857419d0) at rpc/virnetserver.c:1097
      17 0x00007f1b8359db6b in main (argc=2, argv=0x7ffff98dbaa8) at libvirtd.c:1512
      4e5f0dd2
    • S
      libxl: Correctly initialize vcpu bitmap · 65026d72
      Stefan Bader 提交于
      The avail_vcpu bitmap has to be allocated before it can be used (using
      the maximum allowed value for that). Then for each available VCPU the
      bit in the mask has to be set (libxl_bitmap_set takes a bit position
      as an argument, not the number of bits to set).
      
      Without this, I would always only get one VCPU for guests created
      through libvirt/libxl.
      Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
      65026d72
    • J
      Add a colon after 'internal error' · a8843074
      Ján Tomko 提交于
      As we do for other errors with an extra string.
      a8843074