1. 16 5月, 2011 20 次提交
    • D
      Fix VM teardown if prepare returns invalid URI in v2 migration · 6b0fa703
      Daniel P. Berrange 提交于
      The v2 migration protocol was accidentally missing out the
      finish step, when prepare succeeded, but returned an invalid
      URI
      
      * src/libvirt.c: Teardown VM if prepare returns invalid URI
      6b0fa703
    • D
      Refactor tunnelled migration methods · 13cb49f8
      Daniel P. Berrange 提交于
      To facilitate the introduction of the v3 migration protocol,
      the doTunnelMigrate method is refactored into two pieces. One
      piece is intended to mirror the flow of virDomainMigrateVersion2,
      while the other is the helper for setting up sockets and processing
      the data.
      
      Previously socket setup would be done before the 'prepare' step,
      so errors could be dealt with immediately, avoiding need to shut
      off the destination QEMU. In the new split, socket setup is done
      after the 'prepare' step. This is not a serious problem, since
      the control flow already requires calling 'finish' to tear down
      the destination QEMU upon several errors.
      
      * src/qemu/qemu_migration.c:
      13cb49f8
    • D
      Wire up SPICE client relocation with QEMU migration · cc53b4c4
      Daniel P. Berrange 提交于
      Use the graphics information from the QEMU migration cookie to
      issue a 'client_migrate_info' monitor command to QEMU. This causes
      the SPICE client to automatically reconnect to the target host
      when migration completes
      
      * src/qemu/qemu_migration.c: Set data for SPICE client relocation
        before starting migration on src
      * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
        src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h,
        src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add
        new qemuMonitorGraphicsRelocate() command
      cc53b4c4
    • D
      Pass graphics setup from dst back to src via migration cookies · 72de0d28
      Daniel P. Berrange 提交于
      Extend the QEMU migration cookie structure to allow information
      about the destination host graphics setup to be passed by to
      the source host. This will enable seamless migration of any
      connected graphics clients
      
      * src/qemu/qemu_migration.c: Add graphics info to migration
        cookies
      * daemon/libvirtd.c: Always initialize gnutls to enable
        x509 cert parsing in QEMU
      72de0d28
    • D
      Introduce migration cookies to QEMU driver · 8654175c
      Daniel P. Berrange 提交于
      The migration protocol has support for a 'cookie' parameter which
      is an opaque array of bytes as far as libvirt is concerned. Drivers
      may use this for passing around arbitrary extra data they might
      need during migration. The QEMU driver needs to do a few things:
      
       - Pass hostname/uuid to allow strict protection against localhost
         migration attempts
       - Pass SPICE/VNC server port from the target back to the source to
         allow seamless relocation of client sessions
       - Pass lock driver state from source to destination
      
      This patch introduces the basic glue for handling cookies
      but only includes the host/guest UUID & name.
      
      * src/libvirt_private.syms: Export virXMLParseStrHelper
      * src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Parsing
        and formatting of migration cookies
      * src/qemu/qemu_driver.c: Pass in cookie parameters where possible
      * src/remote/remote_protocol.h, src/remote/remote_protocol.x: Change
        cookie max length to 16384 bytes
      8654175c
    • 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
      Automatically generate the hvsupport.html.in file from source files · 4ffc6d17
      Daniel P. Berrange 提交于
      The hvsupport.html.in file is forever out of date. By annotating
      the driver struct tables in each driver with version information,
      we can auto-generate the hvsupport.html.in file. Annotating the
      drivers will be mandatory for new patches, ensuring hvsupport.html.in
      is never out of date again.
      
      * docs/hvsupport.html.in: Delete
      * hvsupport.pl: Script to generate hvsupport.html.in
      * Makefile.am: Autogenerate hvsupport.html.in
      4ffc6d17
    • 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
      0eaf4d93
    • 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 20 次提交