1. 16 9月, 2015 2 次提交
    • J
      libxl: fix compiler error introduced by commit ba25c214 · a4604eb0
      Jim Fehlig 提交于
      libxl/libxl_conf.c: In function 'libxlDriverConfigNew':
      libxl/libxl_conf.c:1560:30: error: 'log_level' may be used uninitialized
      in this function [-Werror=maybe-uninitialized]
      a4604eb0
    • J
      libxl: open libxl log stream with libvirtd log_level · ba25c214
      Jim Fehlig 提交于
      Instead of a hardcoded DEBUG log level, use the overall
      daemon log level specified in libvirtd.conf when opening
      a log stream with libxl. libxl is very verbose when DEBUG
      log level is set, resulting in huge log files that can
      potentially fill a disk. Control of libxl verbosity should
      be placed in the administrator's hands.
      ba25c214
  2. 15 9月, 2015 6 次提交
  3. 14 9月, 2015 4 次提交
  4. 12 9月, 2015 2 次提交
    • C
      qemu: command: Report stderr from qemu-bridge-helper · db35beaa
      Cole Robinson 提交于
      There's a couple reports of things failing in this area (bug 1259070),
      but it's tough to tell what's going wrong without stderr from
      qemu-bridge-helper. So let's report stderr in the error message
      
      Couple new examples:
      
      virbr0 is inactive:
      internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=21: failed to communicate with bridge helper: Transport endpoint is not connected
      stderr=failed to get mtu of bridge `virbr0': No such device
      
      bridge isn't on the ACL:
      internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=br0 --fd=21: failed to communicate with bridge helper: Transport endpoint is not connected
      stderr=access denied by acl file
      db35beaa
    • D
      xen: fix race in refresh of config cache · 427067f7
      Daniel P. Berrange 提交于
      The xenXMConfigCacheRefresh method scans /etc/xen and loads
      all config files it finds. It then scans its internal hash
      table and purges any (previously) loaded config files whose
      refresh timestamp does not match the timestamp recorded at
      the start of xenXMConfigCacheRefresh(). There is unfortunately
      a subtle flaw in this, because if loading the config files
      takes longer than 1 second, some of the config files will
      have a refresh timestamp that is 1 or more seconds different
      (newer) than is checked for. So we immediately purge a bunch
      of valid config files we just loaded.
      
      To avoid this flaw, we must pass the timestamp we record at
      the start of xenXMConfigCacheRefresh() into the
      xenXMConfigCacheAddFile() method, instead of letting the
      latter call time(NULL) again.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      427067f7
  5. 11 9月, 2015 2 次提交
  6. 10 9月, 2015 5 次提交
  7. 09 9月, 2015 3 次提交
  8. 08 9月, 2015 6 次提交
  9. 07 9月, 2015 4 次提交
  10. 05 9月, 2015 6 次提交