1. 16 5月, 2011 13 次提交
    • D
      Fix locking with qemuMigrationPrepareTunnel method · 9ab24558
      Daniel P. Berrange 提交于
      The qemuMigrationPrepareTunnel method should not unlock the
      qemu driver, since that is the caller's job.
      
      * src/qemu/qemu_migration.c: Fix qemuMigrationPrepareTunnel
        unlocking of QEMU driver
      9ab24558
    • D
      Remote driver implementation of new migration API · d59e14a1
      Daniel P. Berrange 提交于
      * src/remote/remote_protocol.x: Define wire protocol for migration
        protocol v3
      * daemon/remote.c: Server side dispatch
      * src/remote/remote_driver.c: Client side serialization
      * src/remote/remote_protocol.c, src/remote/remote_protocol.h,
        daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h,
        daemon/remote_dispatch_ret.h, daemon/remote_dispatch_table.h:
        Re-generate files
      * src/remote_protocol-structs: Declare new ABIs
      d59e14a1
    • D
      Introduce yet another migration version in API. · 65043d2d
      Daniel P. Berrange 提交于
      Migration just seems to go from bad to worse. We already had to
      introduce a second migration protocol when adding the QEMU driver,
      since the one from Xen was insufficiently flexible to cope with
      passing the data the QEMU driver required.
      
      It turns out that this protocol still has some flaws that we
      need to address. The current sequence is
      
       *  Src: DumpXML
                - Generate XML to pass to dst
      
       *  Dst: Prepare
                - Get ready to accept incoming VM
                - Generate optional cookie to pass to src
      
       *  Src: Perform
                - Start migration and wait for send completion
                - Kill off VM if successful, resume if failed
      
       *  Dst: Finish
                - Wait for recv completion and check status
                - Kill off VM if unsuccessful
      
      The problems with this are:
      
       - Since the first step is a generic 'DumpXML' call, we can't
         add in other migration specific data. eg, we can't include
         any VM lease data from lock manager plugins
       - Since the first step is a generic 'DumpXML' call, we can't
         emit any 'migration begin' event on the source, or have
         any hook that runs right at the start of the process
       - Since there is no final step on the source, if the Finish
         method fails to receive all migration data & has to kill
         the VM, then there's no way to resume the original VM
         on the source
      
      This patch attempts to introduce a version 3 that uses the
      improved 5 step sequence
      
       *  Src: Begin
                - Generate XML to pass to dst
                - Generate optional cookie to pass to dst
      
       *  Dst: Prepare
                - Get ready to accept incoming VM
                - Generate optional cookie to pass to src
      
       *  Src: Perform
                - Start migration and wait for send completion
                - Generate optional cookie to pass to dst
      
       *  Dst: Finish
                - Wait for recv completion and check status
                - Kill off VM if failed, resume if success
                - Generate optional cookie to pass to src
      
       *  Src: Confirm
                - Kill off VM if success, resume if failed
      
      The API is designed to allow both input and output cookies
      in all methods where applicable. This lets us pass around
      arbitrary extra driver specific data between src & dst during
      migration. Combined with the extra 'Begin' method this lets
      us pass lease information from source to dst at the start of
      migration
      
      Moving the killing of the source VM out of Perform and
      into Confirm, means we can now recover if the dst host
      can't successfully Finish receiving migration data.
      65043d2d
    • D
      Add many version number annotations to drivers · 9b1ae97f
      Daniel P. Berrange 提交于
      Add many version number annotations to the internal driver
      tables, to allow hvsupport.html to display more accurate
      information
      9b1ae97f
    • D
      Convert all driver struct intializers to C99 style · 879d409e
      Daniel P. Berrange 提交于
      Change all the driver struct initializers to use the
      C99 style, leaving out unused fields. This will make
      it possible to add new APIs without changing every
      driver. eg change:
      
          qemudDomainResume, /* domainResume */
          qemudDomainShutdown, /* domainShutdown */
          NULL, /* domainReboot */
          qemudDomainDestroy, /* domainDestroy */
      
      to
      
          .domainResume = qemudDomainResume,
          .domainShutdown = qemudDomainShutdown,
          .domainDestroy = qemudDomainDestroy,
      
      And get rid of any existing C99 style initializersr which
      set NULL, eg change
      
           .listPools          = vboxStorageListPools,
           .numOfDefinedPools  = NULL,
           .listDefinedPools   = NULL,
           .findPoolSources    = NULL,
           .poolLookupByName   = vboxStoragePoolLookupByName,
      
      to
      
           .listPools          = vboxStorageListPools,
           .poolLookupByName   = vboxStoragePoolLookupByName,
      879d409e
    • D
      Tweak driver naming for consistency with public API · 360df019
      Daniel P. Berrange 提交于
      Fix some driver names:
      
        s/virDrvCPUCompare/virDrvCompareCPU/
        s/virDrvCPUBaseline/virDrvBaselineCPU/
        s/virDrvQemuDomainMonitorCommand/virDrvDomainQemuMonitorCommand/
        s/virDrvSecretNumOfSecrets/virDrvNumOfSecrets/
        s/virDrvSecretListSecrets/virDrvListSecrets/
      
      And some driver struct field names:
      
        s/getFreeMemory/nodeGetFreeMemory/
      360df019
    • J
      qemu: Update domain state when reconnecting monitor · 9f131961
      Jiri Denemark 提交于
      A qemu domain can get paused when libvirtd is stopped (e.g., because of
      I/O error) so we should check its current state when reconnecting to it.
      9f131961
    • J
      Implement domain state reason · b046c55d
      Jiri Denemark 提交于
      Only in drivers which use virDomainObj, drivers that query hypervisor
      for domain status need to be updated separately in case their hypervisor
      supports this functionality.
      
      The reason is also saved into domain state XML so if a domain is not
      running (i.e., no state XML exists) the reason will be lost by libvirtd
      restart. I think this is an acceptable limitation.
      b046c55d
    • J
      Implement basic virDomainGetState in all drivers · 26d94012
      Jiri Denemark 提交于
      Reason is currently always set to 0 (i.e., *_UNKNOWN).
      26d94012
    • J
      9f181ebc
    • J
      virDomainGetState public API implementation · 46b95e64
      Jiri Denemark 提交于
      46b95e64
    • J
      Internal driver API for virDomainGetState · 6feb1341
      Jiri Denemark 提交于
      6feb1341
    • J
      virDomainGetState public API · d65a924b
      Jiri Denemark 提交于
      This API is supposed to replace virDomainGetInfo when the only purpose
      of calling it is getting current domain status.
      d65a924b
  2. 14 5月, 2011 17 次提交
  3. 13 5月, 2011 10 次提交