1. 28 11月, 2012 11 次提交
  2. 26 11月, 2012 2 次提交
  3. 23 11月, 2012 1 次提交
    • D
      Fix exiting of libvirt_lxc program on container quit · 37db3f5d
      Daniel P. Berrange 提交于
      The virLXCControllerClientCloseHook method was mistakenly
      assuming that the private data associated with the network
      client was the virLXCControllerPtr. In fact it was just a
      dummy int, so we were derefencing a bogus struct. The
      frequent result of this was that we would never quit, because
      we tried to arm a non-existant timer.
      
      Fix the code by removing the dummy private data and just
      using the virLXCControllerPtr instance as private data
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      37db3f5d
  4. 22 11月, 2012 2 次提交
    • D
      Log an audit message with the LXC init pid · a6158336
      Daniel P. Berrange 提交于
      Currently the LXC driver logs audit messages when a container
      is started or stopped. These audit messages, however, contain
      the PID of the libvirt_lxc supervisor process. To enable
      sysadmins to correlate with audit messages generated by
      processes /inside/ the container, we need to include the
      container init process PID.
      
      We can't do this in the main 'start' audit message, since
      the init PID is not available at that point. Instead we output
      a completely new audit record, that lists both PIDs.
      
      type=VIRT_CONTROL msg=audit(1353433750.071:363): pid=20180 uid=0 auid=501 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='virt=lxc op=init vm="busy" uuid=dda7b947-0846-1759-2873-0f375df7d7eb vm-pid=20371 init-pid=20372 exe="/home/berrange/src/virt/libvirt/daemon/.libs/lt-libvirtd" hostname=? addr=? terminal=pts/6 res=success'
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a6158336
    • D
      Use virNetServerRun instead of custom main loop · f33e43c2
      Daniel P. Berrange 提交于
      The LXC controller code currently directly invokes the
      libvirt main loop code. The problem is that this misses
      the cleanup of virNetServerClient connections that
      virNetServerRun takes care of.
      
      The result is that when libvirtd is stopped, the
      libvirt_lxc controller process gets stuck in a I/O loop.
      When libvirtd is then started again, it fails to connect
      to the controller and thus kills off the entire domain.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      f33e43c2
  5. 15 11月, 2012 1 次提交
  6. 14 11月, 2012 1 次提交
  7. 10 11月, 2012 1 次提交
    • V
      capabilities: defaultConsoleTargetType can depend on architecture · b1c88c14
      Viktor Mihajlovski 提交于
      For S390, the default console target type cannot be of type 'serial'.
      It is necessary to at least interpret the 'arch' attribute
      value of the os/type element to produce the correct default type.
      
      Therefore we need to extend the signature of defaultConsoleTargetType
      to account for architecture. As a consequence all the drivers
      supporting this capability function must be updated.
      
      Despite the amount of changed files, the only change in behavior is
      that for S390 the default console target type will be 'virtio'.
      
      N.B.: A more future-proof approach could be to to use hypervisor
      specific capabilities to determine the best possible console type.
      For instance one could add an opaque private data pointer to the
      virCaps structure (in case of QEMU to hold capsCache) which could
      then be passed to the defaultConsoleTargetType callback to determine
      the console target type.
      Seems to be however a bit overengineered for the use case...
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      b1c88c14
  8. 02 11月, 2012 2 次提交
  9. 26 10月, 2012 1 次提交
  10. 16 10月, 2012 1 次提交
  11. 02 10月, 2012 1 次提交
    • M
      lxc: Correctly report active cgroups · 0dddd680
      Michal Privoznik 提交于
      There was an inverted return value in lxcCgroupControllerActive().
      The function assumes cgroups are active and do couple of checks
      to prove that. If any of them fails, false is returned. Therefore,
      at the end, after all checks are done we must return true, not false.
      0dddd680
  12. 27 9月, 2012 2 次提交
    • D
      Use size_t instead of int for virDomainDefPtr struct · 5cbb0d37
      Daniel P. Berrange 提交于
      Many parts of virDomainDefPtr were using 'int' variables as
      array length counts. Replace all these with size_t and update
      various format strings & API signatures to adapt
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      5cbb0d37
    • D
      Fix deadlock in handling EOF in LXC monitor · 36c1fc18
      Daniel P. Berrange 提交于
      Depending on the scenario in which LXC containers exit, it is
      possible for the EOF callback of the LXC monitor to deadlock
      the driver.
      
        #0  0x00000038a0a0de4d in __lll_lock_wait () from /lib64/libpthread.so.0
        #1  0x00000038a0a09ca6 in _L_lock_840 () from /lib64/libpthread.so.0
        #2  0x00000038a0a09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0
        #3  0x00007f4bd9579d55 in virMutexLock (m=<optimized out>) at util/threads-pthread.c:85
        #4  0x00007f4bcacc7597 in lxcDriverLock (driver=0x7f4bc40c8290) at lxc/lxc_conf.h:81
        #5  virLXCProcessMonitorEOFNotify (mon=<optimized out>, vm=0x7f4bb4000b00) at lxc/lxc_process.c:581
        #6  0x00007f4bd9645c91 in virNetClientCloseLocked (client=client@entry=0x7f4bb4009e60)
            at rpc/virnetclient.c:554
        #7  0x00007f4bd96460f8 in virNetClientIOEventLoopPassTheBuck (thiscall=0x0, client=0x7f4bb4009e60)
            at rpc/virnetclient.c:1306
        #8  virNetClientIOEventLoopPassTheBuck (client=0x7f4bb4009e60, thiscall=0x0)
            at rpc/virnetclient.c:1287
        #9  0x00007f4bd96467a2 in virNetClientCloseInternal (reason=3, client=0x7f4bb4009e60)
            at rpc/virnetclient.c:589
        #10 virNetClientCloseInternal (client=0x7f4bb4009e60, reason=3) at rpc/virnetclient.c:561
        #11 0x00007f4bcacc4a82 in virLXCMonitorClose (mon=0x7f4bb4000a00) at lxc/lxc_monitor.c:201
        #12 0x00007f4bcacc55ac in virLXCProcessCleanup (reason=<optimized out>, vm=0x7f4bb4000b00,
            driver=0x7f4bc40c8290) at lxc/lxc_process.c:240
        #13 virLXCProcessStop (driver=0x7f4bc40c8290, vm=vm@entry=0x7f4bb4000b00,
            reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:735
        #14 0x00007f4bcacc5bd2 in virLXCProcessAutoDestroyDom (payload=<optimized out>,
            name=0x7f4bb4003c80, opaque=0x7fff41af2df0) at lxc/lxc_process.c:94
        #15 0x00007f4bd9586649 in virHashForEach (table=0x7f4bc409b270,
            iter=iter@entry=0x7f4bcacc5ab0 <virLXCProcessAutoDestroyDom>, data=data@entry=0x7fff41af2df0)
            at util/virhash.c:514
        #16 0x00007f4bcacc52d7 in virLXCProcessAutoDestroyRun (driver=driver@entry=0x7f4bc40c8290,
            conn=conn@entry=0x7f4bb8000ab0) at lxc/lxc_process.c:120
        #17 0x00007f4bcacca628 in lxcClose (conn=0x7f4bb8000ab0) at lxc/lxc_driver.c:128
        #18 0x00007f4bd95e67ab in virReleaseConnect (conn=conn@entry=0x7f4bb8000ab0) at datatypes.c:114
      
      When the driver calls virLXCMonitorClose, there is really no
      need for the EOF callback to be invoked in this case, since
      the caller can easily handle events itself. In changing this,
      the monitor needs to take a deep copy of the callback list,
      not merely a reference.
      
      Also adds debug statements in various places to aid
      troubleshooting
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      36c1fc18
  13. 26 9月, 2012 5 次提交
  14. 21 9月, 2012 3 次提交
  15. 18 9月, 2012 3 次提交
  16. 17 9月, 2012 1 次提交
  17. 07 9月, 2012 1 次提交
  18. 30 8月, 2012 1 次提交
    • L
      network: get vlan info for Open vSwitch interfaces from proper source · b3bd5d6c
      Laine Stump 提交于
      This bug was revealed by the crash described in
      
        https://bugzilla.redhat.com/show_bug.cgi?id=852383
      
      The vlan info pointer sent to virNetDevOpenvswitchAddPort should never
      be non-NULL unless there is at least one tag. The factthat such a vlan
      info pointer was receveid pointed out that a caller was passing the
      wrong pointer. Instead of sending &net->vlan, the result of
      virDomainNetGetActualVlan(net) should be sent - that function will
      look for vlan info in net->data.network.actual->vlan, and in cany case
      return NULL instead of a pointer if the vlan info it finds has no
      tags.
      
      Aside from causing the crash, sending a hardcoded &net->vlan has the
      effect of ignoring vlan info from a <network> or <portgroup> config.
      b3bd5d6c