qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
Date: Fri, 14 Sep 2012 17:23:16 -0600	[thread overview]
Message-ID: <5053BC64.90900@redhat.com> (raw)
In-Reply-To: <20120914174725.GK6819@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

[adding qemu]

On 09/14/2012 11:47 AM, Daniel P. Berrange wrote:
> On Fri, Sep 14, 2012 at 07:34:50PM +0200, Michal Privoznik wrote:
>> With this element users will control how SPICE
>> server behaves upon migration. For now, there's
>> just one attribute 'seamless' turning seamless
>> migration on/off/default.
> 
> Ewww, no. This information is a related to a API operation,
> not the VM configuration. It should be either auto-detected
> by libvirt to the best compatible setting, or passed as a
> flag to the virDomainMigrate API call if auto-detection is
> not possible.

But with the current qemu implementation, there's no way to know if the
destination supports this until after you've started the source, and the
current implementation in qemu is that you must declare the semantics at
the time you start qemu, not at the time you send the 'migrate' monitor
command.  For libvirt autodetection to work without polluting the domain
XML, we'd need to be able to auto-detect at the time we start migration.

This sounds like we need to enhance the 'migrate-set-capabilities'
command to enable or disable this feature on the fly, according to what
libvirt detects from the remote end, rather than hard-coding it to the
startup state of qemu on the source side.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]

       reply	other threads:[~2012-09-14 23:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1347643232.git.mprivozn@redhat.com>
     [not found] ` <ee72d804f56795773b84e5e0aa0623a224cf5a9f.1347643232.git.mprivozn@redhat.com>
     [not found]   ` <20120914174725.GK6819@redhat.com>
2012-09-14 23:23     ` Eric Blake [this message]
2012-09-15 15:10       ` [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics Daniel P. Berrange
2012-09-19 13:26         ` Michal Privoznik
2012-09-19 14:21           ` Daniel P. Berrange
2012-09-19 14:25           ` Daniel P. Berrange
2012-09-19 16:13             ` Michal Privoznik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5053BC64.90900@redhat.com \
    --to=eblake@redhat.com \
    --cc=berrange@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).