1. 28 4月, 2015 2 次提交
  2. 27 4月, 2015 1 次提交
    • M
      monitor: Make client_migrate_info synchronous · 3b5704b2
      Markus Armbruster 提交于
      Live migration with spice works like this today:
      
        (1) client_migrate_info monitor cmd
        (2) spice server notifies client, client connects to target host.
        (3) qemu waits until spice client connect is finished.
        (4) send over vmstate (i.e. main part of live migration).
        (5) spice handover to target host.
      
      (3) is implemented by making client_migrate_info a async monitor
      command.  This is the only async monitor command we have.
      
      The original reason to implement this dance was that qemu did not accept
      new tcp connections while the incoming migration was running, so (2) and
      (4) could not be done in parallel.  That issue was fixed long ago though.
      Qemu version 1.3.0 (released Dec 2012) and newer happily accept tcp
      connects while the incoming migration runs.
      
      Time to drop step (3).  This patch does exactly that, by making the
      monitor command synchronous and removing the code needed to handle the
      async monitor command in ui/spice-core.c
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      3b5704b2
  3. 25 4月, 2015 1 次提交
    • P
      qmp-commands: fix incorrect uses of ":O" specifier · 43d0a2c1
      Paolo Bonzini 提交于
      As far as the QMP parser is concerned, neither the 'O' nor the 'q' format specifiers
      put any constraint on the command.  However, there are two differences:
      
      1) from a documentation point of view 'O' says that this command takes
      a dictionary.  The dictionary will be converted to QemuOpts in the
      handler to match the corresponding HMP command.
      
      2) 'O' sets QMP_ACCEPT_UNKNOWNS, resulting in the command accepting invalid
      extra arguments.  For example the following is accepted:
      
         { "execute": "send-key",
              "arguments": { "keys": [ { "type": "qcode", "data": "ctrl" },
                                       { "type": "qcode", "data": "alt" },
                                       { "type": "qcode", "data": "delete" } ], "foo": "bar" } }
      
      Neither send-key nor migrate-set-capabilities take a QemuOpts-like
      dictionary; they take an array of dictionaries.  And neither command
      really wants to have extra unknown arguments.  Thus, the right
      specifier to use in this case is 'q'; with this patch the above
      command fails with
      
         {"error": {"class": "GenericError", "desc": "Invalid parameter 'foo'"}}
      
      as intended.
      Reported-by: NAlberto Garcia <berto@igalia.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAlberto Garcia <berto@igalia.com>
      Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
      43d0a2c1
  4. 27 3月, 2015 1 次提交
  5. 19 3月, 2015 2 次提交
  6. 16 3月, 2015 1 次提交
  7. 10 3月, 2015 1 次提交
  8. 07 2月, 2015 2 次提交
    • F
      block: add event when disk usage exceeds threshold · e2462113
      Francesco Romani 提交于
      Managing applications, like oVirt (http://www.ovirt.org), make extensive
      use of thin-provisioned disk images.
      To let the guest run smoothly and be not unnecessarily paused, oVirt sets
      a disk usage threshold (so called 'high water mark') based on the occupation
      of the device,  and automatically extends the image once the threshold
      is reached or exceeded.
      
      In order to detect the crossing of the threshold, oVirt has no choice but
      aggressively polling the QEMU monitor using the query-blockstats command.
      This lead to unnecessary system load, and is made even worse under scale:
      deployments with hundreds of VMs are no longer rare.
      
      To fix this, this patch adds:
      * A new monitor command `block-set-write-threshold', to set a mark for
        a given block device.
      * A new event `BLOCK_WRITE_THRESHOLD', to report if a block device
        usage exceeds the threshold.
      * A new `write_threshold' field into the `BlockDeviceInfo' structure,
        to report the configured threshold.
      
      This will allow the managing application to use smarter and more
      efficient monitoring, greatly reducing the need of polling.
      
      [Updated qemu-iotests 067 output to add the new 'write_threshold'
      property. --Stefan]
      [Changed g_assert_false() to !g_assert() to fix the build on older glib
      versions. --Kevin]
      Signed-off-by: NFrancesco Romani <fromani@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 1421068273-692-1-git-send-email-fromani@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e2462113
    • P
      block: add accounting for merged requests · f4564d53
      Peter Lieven 提交于
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      f4564d53
  9. 22 1月, 2015 1 次提交
    • G
      monitor: add query-vnc-servers command · df887684
      Gerd Hoffmann 提交于
      Add new query vnc qmp command, for the lack of better ideas just name it
      "query-vnc-servers".  Changes over query-vnc:
      
       * It returns a list of vnc servers, so multiple vnc server instances
         are covered.
       * Each vnc server returns a list of server sockets.  Followup patch
         will use that to also report websockets.  In case we add support for
         multiple server sockets server sockets (to better support ipv4+ipv6
         dualstack) we can add them to the list too.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      df887684
  10. 13 1月, 2015 1 次提交
  11. 16 12月, 2014 1 次提交
  12. 10 12月, 2014 2 次提交
  13. 26 11月, 2014 1 次提交
  14. 13 11月, 2014 1 次提交
    • A
      QMP/input-send-event: make console parameter optional · 51fc4476
      Amos Kong 提交于
      The 'QemuConsole' is the input source for handler, we share some
      input handlers to process the input events from different QemuConsole.
      
      Normally we only have one set of keyboard, mouse, usbtablet, etc.
      The devices have different mask, it's fine to just checking mask to
      insure that the handler has the ability to process the event.
      
      I saw we try to bind console to handler in usb/dev-hid.c, but display
      always isn't available at that time.
      
      If we have multiseat setup (as Gerd said), we only have 'problem' in
      this case. Actually event from different devices have the same effect
      for system, it's fine to always use the first available handler
      without caring about the console.
      
      For send-key command, we just pass a NULL for console parameter in
      calling qemu_input_event_send_key(NULL, ..), but 'input-send-event'
      needs to care more devices.
      
      Conclusion:
      Generally assigning the special console is meanless, and we can't
      directly remove the QMP parameter for compatibility.
      
      So we can make the parameter optional. The parameter might be useful
      for some special condition: we have multiple devices without binding
      console and they all have the ability(mask) to process events, and
      we don't want to use the first one.
      
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAmos Kong <akong@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      51fc4476
  15. 02 10月, 2014 1 次提交
  16. 26 9月, 2014 1 次提交
  17. 22 9月, 2014 1 次提交
    • S
      block: delete cow block driver · 550830f9
      Stefan Hajnoczi 提交于
      This patch removes support for the cow file format.
      
      Normally we do not break backwards compatibility but in this case there
      is no impact and it is the most logical option.  Extraordinary claims
      require extraordinary evidence so I will show why removing the cow block
      driver is the right thing to do.
      
      The cow file format is the disk image format for Usermode Linux, a way
      of running a Linux system in userspace.  The performance of UML was
      never great and it was hacky, but it enjoyed some popularity before
      hardware virtualization support became mainstream.
      
      QEMU's block/cow.c is supposed to read this image file format.
      Unfortunately the file format was underspecified:
      
      1. Earlier Linux versions used the MAXPATHLEN constant for the backing
         filename field.  The value of MAXPATHLEN can change, so Linux
         switched to a 4096 literal but QEMU has a 1024 literal.
      
      2. Padding was not used on the header struct (both in the Linux kernel
         and in QEMU) so the struct layout varied across architectures.  In
         particular, i386 and x86_64 were different due to int64_t alignment
         differences.  Linux now uses __attribute__((packed)), QEMU does not.
      
      Therefore:
      
      1. QEMU cow images do not conform to the Linux cow image file format.
      
      2. cow images cannot be shared between different host architectures.
      
      This means QEMU cow images are useless and QEMU has not had bug reports
      from users actually hitting these issues.
      
      Let's get rid of this thing, it serves no purpose and no one will be
      affected.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1410877464-20481-1-git-send-email-stefanha@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      550830f9
  18. 25 8月, 2014 1 次提交
    • A
      cpus: Define callback for QEMU "nmi" command · 9cb805fd
      Alexey Kardashevskiy 提交于
      This introduces an NMI (Non Maskable Interrupt) interface with
      a single nmi_monitor_handler() method. A machine or a device can
      implement it. This searches for an QOM object with this interface
      and if it is implemented, calls it. The callback implements an action
      required to cause debug crash dump on in-kernel debugger invocation.
      The callback returns Error**.
      
      This adds a nmi_monitor_handle() helper which walks through
      all objects to find the interface. The interface method is called
      for all found instances.
      
      This adds support for it in qmp_inject_nmi(). Since no architecture
      supports it at the moment, there is no change in behaviour.
      
      This changes inject-nmi command description for HMP and QMP.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Reviewed-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      9cb805fd
  19. 01 7月, 2014 4 次提交
    • J
      block: add backing-file option to block-stream · 13d8cc51
      Jeff Cody 提交于
      On some image chains, QEMU may not always be able to resolve the
      filenames properly, when updating the backing file of an image
      after a block job.
      
      For instance, certain relative pathnames may fail, or drives may
      have been specified originally by file descriptor (e.g. /dev/fd/???),
      or a relative protocol pathname may have been used.
      
      In these instances, QEMU may lack the information to be able to make
      the correct choice, but the user or management layer most likely does
      have that knowledge.
      
      With this extension to the block-stream api, the user is able to change
      the backing file of the active layer as part of the block-stream
      operation.
      
      This allows the change to be 'safe', in the sense that if the attempt
      to write the active image metadata fails, then the block-stream
      operation returns failure, without disrupting the guest.
      
      If a backing file string is not specified in the command, the backing
      file string to use is determined in the same manner as it was
      previously.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      13d8cc51
    • J
      block: extend block-commit to accept a string for the backing file · 54e26900
      Jeff Cody 提交于
      On some image chains, QEMU may not always be able to resolve the
      filenames properly, when updating the backing file of an image
      after a block commit.
      
      For instance, certain relative pathnames may fail, or drives may
      have been specified originally by file descriptor (e.g. /dev/fd/???),
      or a relative protocol pathname may have been used.
      
      In these instances, QEMU may lack the information to be able to make
      the correct choice, but the user or management layer most likely does
      have that knowledge.
      
      With this extension to the block-commit api, the user is able to change
      the backing file of the overlay image as part of the block-commit
      operation.
      
      This allows the change to be 'safe', in the sense that if the attempt
      to write the overlay image metadata fails, then the block-commit
      operation returns failure, without disrupting the guest.
      
      If the commit top is the active layer, then specifying the backing
      file string will be treated as an error (there is no overlay image
      to modify in that case).
      
      If a backing file string is not specified in the command, the backing
      file string to use is determined in the same manner as it was
      previously.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      54e26900
    • J
      block: add QAPI command to allow live backing file change · fa40e656
      Jeff Cody 提交于
      This allows a user to make a live change to the backing file recorded in
      an open image.
      
      The image file to modify can be specified 2 ways:
      
      1) image filename
      2) image node-name
      
      Note: this does not cause the backing file itself to be reopened; it
      merely changes the backing filename in the image file structure, and
      in internal BDS structures.
      
      It is the responsibility of the user to pass a filename string that
      can be resolved when the image chain is reopened, and the filename
      string is not validated.
      
      A good analogy for this command is that it is a live version of
      'qemu-img rebase -u', with respect to changing the backing file string.
      
      [Jeff is offline so I respun this patch in his absence.  Dropped image
      filename since using node-name is preferred and this is a new command.
      No need to introduce the limitations of finding images by filename.
      --Stefan]
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      fa40e656
    • J
      block: make 'top' argument to block-commit optional · 7676e2c5
      Jeff Cody 提交于
      Now that active layer block-commit is supported, the 'top' argument
      no longer needs to be mandatory.
      
      Change it to optional, with the default being the active layer in the
      device chain.
      
      [kwolf: Rebased and resolved conflict in tests/qemu-iotests/040]
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NBenoit Canet <benoit@irqsave.net>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      7676e2c5
  20. 29 6月, 2014 1 次提交
  21. 28 6月, 2014 1 次提交
  22. 27 6月, 2014 2 次提交
  23. 19 6月, 2014 4 次提交
  24. 16 6月, 2014 1 次提交
  25. 21 5月, 2014 1 次提交
  26. 19 5月, 2014 1 次提交
    • P
      block: optimize zero writes with bdrv_write_zeroes · 465bee1d
      Peter Lieven 提交于
      this patch tries to optimize zero write requests
      by automatically using bdrv_write_zeroes if it is
      supported by the format.
      
      This significantly speeds up file system initialization and
      should speed zero write test used to test backend storage
      performance.
      
      I ran the following 2 tests on my internal SSD with a
      50G QCOW2 container and on an attached iSCSI storage.
      
      a) mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/vdX
      
      QCOW2         [off]     [on]     [unmap]
      -----
      runtime:       14secs    1.1secs  1.1secs
      filesize:      937M      18M      18M
      
      iSCSI         [off]     [on]     [unmap]
      ----
      runtime:       9.3s      0.9s     0.9s
      
      b) dd if=/dev/zero of=/dev/vdX bs=1M oflag=direct
      
      QCOW2         [off]     [on]     [unmap]
      -----
      runtime:       246secs   18secs   18secs
      filesize:      51G       192K     192K
      throughput:    203M/s    2.3G/s   2.3G/s
      
      iSCSI*        [off]     [on]     [unmap]
      ----
      runtime:       8mins     45secs   33secs
      throughput:    106M/s    1.2G/s   1.6G/s
      allocated:     100%      100%     0%
      
      * The storage was connected via an 1Gbit interface.
        It seems to internally handle writing zeroes
        via WRITESAME16 very fast.
      Signed-off-by: NPeter Lieven <pl@kamp.de>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      465bee1d
  27. 09 5月, 2014 1 次提交
  28. 06 5月, 2014 2 次提交