1. 21 10月, 2011 1 次提交
  2. 13 10月, 2011 1 次提交
  3. 12 10月, 2011 1 次提交
  4. 07 10月, 2011 1 次提交
  5. 24 9月, 2011 1 次提交
  6. 09 9月, 2011 1 次提交
  7. 05 9月, 2011 1 次提交
    • L
      Check for source conflicts in storage pools · 5a1f2728
      Lei Li 提交于
      Fix bug #611823 storage driver should prohibit pools with duplicate
      underlying storage.
      
      Add internal API virStoragePoolSourceFindDuplicate() to do uniqueness
      check based on source location infomation for pool type.
      
      * AUTHORS: add Lei Li
      5a1f2728
  8. 02 9月, 2011 2 次提交
  9. 25 8月, 2011 2 次提交
  10. 17 8月, 2011 1 次提交
    • T
      qemu: disk migration verbose progress · 108ca333
      Tom Vijlbrief 提交于
      A virsh command like:
      
      migrate --live --copy-storage-all Guest qemu+ssh://user@host/system
      --persistent --verbose
      
      shows
      
      Migration: [  0 %]
      
      during the storage copy and does not start counting
      until the ram transfer starts
      
      Fix this by scraping optional disk transfer status, and adding it
      into the progress meter.
      108ca333
  11. 15 8月, 2011 1 次提交
  12. 25 7月, 2011 1 次提交
  13. 14 7月, 2011 3 次提交
  14. 12 7月, 2011 1 次提交
    • O
      remote/ssh: support for no_verify. · 9a0e6a8f
      Oskari Saarenmaa 提交于
      Set StrictHostKeyChecking=no to auto-accept new ssh host keys if the
      no_verify extra parameter was specified.  This won't disable host key
      checking for already known hosts.  Includes a test and documentation.
      9a0e6a8f
  15. 11 7月, 2011 1 次提交
    • A
      remote: Fix memory leak · 7518ad75
      Alex Jia 提交于
      Detected in valgrind run:
      
      ==9184== 1 bytes in 1 blocks are definitely lost in loss record 1 of 19
      ==9184==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
      ==9184==    by 0x3073715F78: xdr_array (xdr_array.c:97)
      ==9184==    by 0x4CF97C9: xdr_remote_domain_get_security_label_ret (remote_protocol.c:1696)
      ==9184==    by 0x4D08741: virNetMessageDecodePayload (virnetmessage.c:286)
      ==9184==    by 0x4D00F78: virNetClientProgramCall (virnetclientprogram.c:318)
      ==9184==    by 0x4CE3887: call (remote_driver.c:3933)
      ==9184==    by 0x4CF71C6: remoteDomainGetSecurityLabel (remote_driver.c:1580)
      ==9184==    by 0x4CCA480: virDomainGetSecurityLabel (libvirt.c:7340)
      ==9184==    by 0x41993A: cmdDominfo (virsh.c:2414)
      ==9184==    by 0x411E92: vshCommandRun (virsh.c:12730)
      ==9184==    by 0x4211ED: main (virsh.c:14076)
      ==9184==
      ==9184== 2 bytes in 1 blocks are definitely lost in loss record 2 of 19
      ==9184==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
      ==9184==    by 0x3073715F78: xdr_array (xdr_array.c:97)
      ==9184==    by 0x4CF974F: xdr_remote_node_get_security_model_ret (remote_protocol.c:1713)
      ==9184==    by 0x4D08741: virNetMessageDecodePayload (virnetmessage.c:286)
      ==9184==    by 0x4D00F78: virNetClientProgramCall (virnetclientprogram.c:318)
      ==9184==    by 0x4CE3887: call (remote_driver.c:3933)
      ==9184==    by 0x4CF6F96: remoteNodeGetSecurityModel (remote_driver.c:1648)
      ==9184==    by 0x4CBF799: virNodeGetSecurityModel (libvirt.c:7382)
      ==9184==    by 0x4197D7: cmdDominfo (virsh.c:2394)
      ==9184==    by 0x411E92: vshCommandRun (virsh.c:12730)
      ==9184==    by 0x4211ED: main (virsh.c:14076)
      ==9184==
      ==9184== 8 bytes in 1 blocks are definitely lost in loss record 3 of 19
      ==9184==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
      ==9184==    by 0x3073715F78: xdr_array (xdr_array.c:97)
      ==9184==    by 0x4CF9729: xdr_remote_node_get_security_model_ret (remote_protocol.c:1710)
      ==9184==    by 0x4D08741: virNetMessageDecodePayload (virnetmessage.c:286)
      ==9184==    by 0x4D00F78: virNetClientProgramCall (virnetclientprogram.c:318)
      ==9184==    by 0x4CE3887: call (remote_driver.c:3933)
      ==9184==    by 0x4CF6F96: remoteNodeGetSecurityModel (remote_driver.c:1648)
      ==9184==    by 0x4CBF799: virNodeGetSecurityModel (libvirt.c:7382)
      ==9184==    by 0x4197D7: cmdDominfo (virsh.c:2394)
      ==9184==    by 0x411E92: vshCommandRun (virsh.c:12730)
      ==9184==    by 0x4211ED: main (virsh.c:14076)
      ==9184==
      ==9184== LEAK SUMMARY:
      ==9184==    definitely lost: 11 bytes in 3 blocks
      
      * src/remote/remote_driver.c: Avoid leak on remoteDomainGetSecurityLabel
        and remoteNodeGetSecurityModel.
      7518ad75
  16. 08 7月, 2011 2 次提交
  17. 06 7月, 2011 1 次提交
    • G
      pci: initialize state values on reattach · 416814e6
      Guannan Ren 提交于
      add a new API pciDeviceReAttachInit() in pci.c to initialize state values for nodedev reattach
      
      Initialize three state value of device driver to 1. This is just for a new call to
      qemudNodeDeviceReAttach()
      416814e6
  18. 01 7月, 2011 1 次提交
  19. 27 6月, 2011 1 次提交
  20. 24 6月, 2011 1 次提交
  21. 15 6月, 2011 3 次提交
  22. 03 6月, 2011 2 次提交
  23. 27 5月, 2011 2 次提交
    • T
      openvz: Fix regression in config file parsing · 3aab7f2d
      Taisuke Yamada 提交于
      As reported by Diego Blanco in
      
        https://bugzilla.redhat.com/show_bug.cgi?id=702602
      
      commit f0443765 which replaced openvz_readline to getline(3)
      broke OpenVZ driver as it changed semantics of EOF-handling
      when parsing OpenVZ configuration.
      
      There're several other issues reported with current OpenVZ driver:
      
       #1: unclear error message when parsing "CPUS=" line
       #2: openvz driver goes into crashing loop
       #3: "NETIF=" line in configuration is not parsed correctly
       #4: aborts even when optional parameter is missing
       #5: there's a potential memory leak
      
      This updated patch to fix #[145]. This patch does not fix #[23]
      as I haven't verified these yet, but this at least got me to run
      OpenVZ on libvirt once again.
      3aab7f2d
    • F
      qemu: allow blkstat/blkinfo calls during migration · 18c2a592
      Federico Simoncelli 提交于
      Originally most of libvirt domain-specific calls were blocking
      during a migration.
      A new mechanism to allow specific calls (blkstat/blkinfo) to be
      executed in such condition has been implemented.
      In the long term it'd be desirable to get a more general
      solution to mark further APIs as migration safe, without needing
      special case code.
      
       * src/qemu/qemu_migration.c: add some additional job signal
         flags for doing blkstat/blkinfo during a migration
       * src/qemu/qemu_domain.c: add a condition variable that can be
         used to efficiently wait for the migration code to clear the
         signal flag
       * src/qemu/qemu_driver.c: execute blkstat/blkinfo using the
         job signal flags during migration
      18c2a592
  24. 24 5月, 2011 1 次提交
  25. 18 5月, 2011 1 次提交
  26. 06 5月, 2011 1 次提交
  27. 01 5月, 2011 1 次提交
  28. 29 4月, 2011 1 次提交
  29. 26 4月, 2011 1 次提交
  30. 17 4月, 2011 1 次提交
  31. 16 4月, 2011 1 次提交