1. 27 9月, 2012 28 次提交
    • D
      Remove some unused includes in QEMU code · c25746c2
      Daniel P. Berrange 提交于
      The qemu monitor does not require qemu_conf.h, and the
      qemu capabilities code actually wants bitmap.h
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      c25746c2
    • D
      Add a qemuMonitorGetTargetArch() method for QMP query-target command · 364a77ff
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetTargetArch() method to support invocation
      of the 'query-target' JSON monitor command. No HMP equivalent
      is required, since this will only be present for QEMU >= 1.2
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      364a77ff
    • D
      Add a qemuMonitorGetObjectProps() method for QMP device-list-properties command · b785cec0
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetObjectProps() method to support invocation
      of the 'device-list-properties' JSON monitor command. No HMP equivalent
      is required, since this will only be present for QEMU >= 1.2
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      b785cec0
    • D
      Add a qemuMonitorGetObjectTypes() method for QMP qom-list-types command · 2ccaa8e6
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetObjectTypes() method to support invocation
      of the 'qom-list-types' JSON monitor command. No HMP equivalent
      is required, since this will only be present for QEMU >= 1.2
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      2ccaa8e6
    • D
      Add a qemuMonitorGetEvents() method for QMP query-events command · 3b565d3f
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetEvents() method to support invocation
      of the 'query-events' JSON monitor command. No HMP equivalent
      is required, since this will only be used when JSON is available
      
      The existing qemuMonitorJSONCheckEvents() method is refactored
      to use this new method
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3b565d3f
    • D
      Add a qemuMonitorGetCommands() method for QMP query-commands command · c70a6154
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetCPUCommands() method to support invocation
      of the 'query-commands' JSON monitor command. No HMP equivalent
      is required, since this will only be used when JSON is available
      
      The existing qemuMonitorJSONCheckCommands() method is refactored
      to use this new method
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      c70a6154
    • D
      Add a qemuMonitorGetCPUDefinitions method for QMP query-cpu-definitions command · 2ecec6e2
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetCPUDefinitions() method to support invocation
      of the 'query-cpu-definitions' JSON monitor command. No HMP equivalent
      is required, since this will only be present for QEMU >= 1.2
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      2ecec6e2
    • D
      Add a qemuMonitorGetMachines() method for QMP query-machines command · 39993721
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetMachines() method to support invocation
      of the 'query-machines' JSON monitor command. No HMP equivalent
      is required, since this will only be present for QEMU >= 1.2
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      39993721
    • D
      Add a qemuMonitorGetVersion() method for QMP query-version command · 3dce0a82
      Daniel P. Berrange 提交于
      Add a new qemuMonitorGetVersion() method to support invocation
      of the 'query-version' JSON monitor command. No HMP equivalent
      is provided, since this will only be used for QEMU >= 1.2
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3dce0a82
    • D
    • D
      Remove xenner support · de9be0ab
      Daniel P. Berrange 提交于
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      de9be0ab
    • D
      Make qemuCapsProbeMachineTypes & qemuCapsProbeCPUModels static · ca58a1b0
      Daniel P. Berrange 提交于
      The qemuCapsProbeMachineTypes & qemuCapsProbeCPUModels methods
      do not need to be invoked directly anymore. Make them static
      and refactor them to directly populate the qemuCapsPtr object
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      ca58a1b0
    • D
      Remove probing of CPU models when launching QEMU guests · ed769e18
      Daniel P. Berrange 提交于
      When launching a QEMU guest the binary is probed to discover
      the list of supported CPU names. Remove this probing with a
      simple lookup of CPU models in the qemuCapsPtr object. This
      avoids another invocation of the QEMU binary during the
      startup path.
      
      As a nice benefit we can now remove all the nasty hacks from
      the test suite which were done to avoid having to exec QEMU
      on the test system. The building of the -cpu command line
      can just rely on data we pre-populate in qemuCapsPtr.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      ed769e18
    • D
      Remove probing of machine types when canonicalizing XML · bd66c243
      Daniel P. Berrange 提交于
      When XML for a new guest is received, the machine type is
      immediately canonicalized into the version specific name.
      This involves probing QEMU for supported machine types.
      Replace this probing with a lookup of the machine types
      in the (hopefully cached) qemuCapsPtr object
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      bd66c243
    • D
      Remove probing of flags when launching QEMU guests · 15ee6614
      Daniel P. Berrange 提交于
      Remove all use of the existing APIs for querying QEMU
      capability flags. Instead obtain a qemuCapsPtr object
      from the global cache. This avoids the execution of
      'qemu -help' (and related commands) when launching new
      guests.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      15ee6614
    • D
      Switch over to use cache for building QEMU capabilities · 494e2f5c
      Daniel P. Berrange 提交于
      When building up a virCapsPtr instance, the QEMU driver
      was copying the list of machine types across from the
      previous virCapsPtr instance, if the QEMU binary had not
      changed. Replace this ad-hoc caching of data with use
      of the new qemuCapsCache global cache.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      494e2f5c
    • D
      Add a qemu capabilities cache manager · 85a7b5e1
      Daniel P. Berrange 提交于
      Introduce a qemuCapsCachePtr object to provide a global cache
      of capabilities for QEMU binaries. The cache auto-populates
      on first request for capabilities about a binary, and will
      auto-refresh if the binary has changed since a previous cache
      was populated
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      85a7b5e1
    • D
      Fix handling of itanium arch name in QEMU driver · 3887afbb
      Daniel P. Berrange 提交于
      For historical compat we use 'itanium' as the arch name, so
      if the QEMU binary suffix is 'ia64' we need to translate it
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3887afbb
    • D
      Fix potential deadlock when agent is closed · 362d0477
      Daniel P. Berrange 提交于
      If the qemuAgentClose method is called from a place which holds
      the domain lock, it is theoretically possible to get a deadlock
      in the agent destroy callback. This has not been observed, but
      the equivalent code in the QEMU monitor destroy callback has seen
      a deadlock.
      
      Remove the redundant locking while unrefing the object and the
      bogus assignment
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      362d0477
    • 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 (rare) deadlock in QEMU monitor callbacks · 25f582e3
      Daniel P. Berrange 提交于
      Some users report (very rarely) seeing a deadlock in the QEMU
      monitor callbacks
      
       Thread 10 (Thread 0x7fcd11e20700 (LWP 26753)):
       #0  0x00000030d0e0de4d in __lll_lock_wait () from /lib64/libpthread.so.0
       #1  0x00000030d0e09ca6 in _L_lock_840 () from /lib64/libpthread.so.0
       #2  0x00000030d0e09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0
       #3  0x00007fcd162f416d in virMutexLock (m=<optimized out>)
           at util/threads-pthread.c:85
       #4  0x00007fcd1632c651 in virDomainObjLock (obj=<optimized out>)
           at conf/domain_conf.c:14256
       #5  0x00007fcd0daf05cc in qemuProcessHandleMonitorDestroy (mon=0x7fcccc0029e0,
           vm=0x7fcccc00a850) at qemu/qemu_process.c:1026
       #6  0x00007fcd0db01710 in qemuMonitorDispose (obj=0x7fcccc0029e0)
           at qemu/qemu_monitor.c:249
       #7  0x00007fcd162fd4e3 in virObjectUnref (anyobj=<optimized out>)
           at util/virobject.c:139
       #8  0x00007fcd0db027a9 in qemuMonitorClose (mon=<optimized out>)
           at qemu/qemu_monitor.c:860
       #9  0x00007fcd0daf61ad in qemuProcessStop (driver=driver@entry=0x7fcd04079d50,
           vm=vm@entry=0x7fcccc00a850,
           reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED, flags=flags@entry=0)
           at qemu/qemu_process.c:4057
       #10 0x00007fcd0db323cf in qemuDomainDestroyFlags (dom=<optimized out>,
           flags=<optimized out>) at qemu/qemu_driver.c:1977
       #11 0x00007fcd1637ff51 in virDomainDestroyFlags (
           domain=domain@entry=0x7fccf00c1830, flags=1) at libvirt.c:2256
      
      At frame #10 we are holding the domain lock, we call into
      qemuProcessStop() to cleanup QEMU, which triggers the monitor
      to close, which invokes qemuProcessHandleMonitorDestroy() which
      tries to obtain the domain lock again. This is a non-recursive
      lock, hence hang.
      
      Since qemuMonitorPtr is a virObject, the unref call in
      qemuProcessHandleMonitorDestroy no longer needs mutex
      protection. The assignment of priv->mon = NULL, can be
      instead done by the caller of qemuMonitorClose(), thus
      removing all need for locking.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      25f582e3
    • D
      Don't skip over socket label cleanup · 0b62c073
      Daniel P. Berrange 提交于
      If QEMU quits immediately after we opened the monitor it was
      possible we would skip the clearing of the SELinux process
      socket context
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0b62c073
    • D
      Move most of qemuProcessKill into virProcessKillPainfully · 8fd38231
      Daniel P. Berrange 提交于
      In the cgroups APIs we have a virCgroupKillPainfully function
      which does the loop sending SIGTERM, then SIGKILL and waiting
      for the process to exit. There is similar functionality for
      simple processes in qemuProcessKill, but it is tangled with
      the QEMU code. Untangle it to provide a virProcessKillPainfuly
      function
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      8fd38231
    • D
      Don't ignore return value of qemuProcessKill · f1b4021b
      Daniel P. Berrange 提交于
      When calling qemuProcessKill from the virDomainDestroy impl
      in QEMU, do not ignore the return value. This ensures that
      if QEMU fails to respond to SIGKILL, the caller will know
      about the failure.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      f1b4021b
    • 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
    • J
      Support Xen sysctl version 9 in Xen 4.2 · 371ddc98
      Jim Fehlig 提交于
      Xen upstream c/s 24102:dc8e55c9 bumped the sysctl version to 9.
      Support this sysctl version in the xen_hypervisor sub-driver.
      371ddc98
    • L
      network: backend for virNetworkUpdate of interface list · 024879e5
      Laine Stump 提交于
      <interface> elements are location inside the <forward> element of a
      network. There is only one <forward> element in any network, but it
      might have many <interface> elements. This element only contains a
      single attribute, "dev", which is the name of a network device
      (e.g. "eth0").
      
      Since there is only a single attribute, the modify operation isn't
      supported for this "section", only add-first, add-last, and
      delete. Also, note that it's not permitted to delete an interface from
      the list while any guest is using it. We may later decide this is safe
      (because removing it from the list really only excludes it from
      consideration in future guest allocations of interfaces, but doesn't
      affect any guests currently connected), but for now this limitation
      seems prudent (of course when changing the persistent config, this
      limitation doesn't apply, because the persistent config doesn't
      support the concept of "in used").
      
      Another limitation - it is also possible for the interfraces in this
      list to be described by PCI address rather than netdev name. However,
      I noticed while writing this function that we currently don't support
      defining interfaces that way in config - the only method of getting
      interfaces specified as <adress type='pci' ..../> instead of
      <interface dev='xx'/> is to provide a <pf dev='yy'/> element under
      forward, and let the entries in the interface list be automatically
      populated with the virtual functions (VF) of the physical function
      device given in <pg>.
      
      As with the other virNetworkUpdate section backends, support for this
      section is completely contained within a single static function, no
      other changes were required, and only functions already called from
      elsewhere within the same file are used in the new content for this
      existing function (i.e., adding this code should not cause a new build
      problem on any platform).
      024879e5
    • E
      build: avoid older gcc warning · 3da355e8
      Eric Blake 提交于
      Jim Fehlig reported a compilation error with older gcc 4.3.4:
      
      libvirt.c: In function 'virDomainGetEmulatorPinInfo':
      libvirt.c:9111: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op]
      
      It looks like someone programmed via too much copy-and-paste.
      
      * src/libvirt.c (virDomainGetEmulatorPinInfo): Multiplying by 1 is
      a no-op, and thus will never overflow.
      3da355e8
  2. 26 9月, 2012 12 次提交