* Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
[not found] ` <20120914174725.GK6819@redhat.com>
@ 2012-09-14 23:23 ` Eric Blake
2012-09-15 15:10 ` Daniel P. Berrange
0 siblings, 1 reply; 6+ messages in thread
From: Eric Blake @ 2012-09-14 23:23 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: libvir-list, Michal Privoznik, QEMU Developers
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
2012-09-14 23:23 ` [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics Eric Blake
@ 2012-09-15 15:10 ` Daniel P. Berrange
2012-09-19 13:26 ` Michal Privoznik
0 siblings, 1 reply; 6+ messages in thread
From: Daniel P. Berrange @ 2012-09-15 15:10 UTC (permalink / raw)
To: Eric Blake; +Cc: libvir-list, Michal Privoznik, QEMU Developers
On Fri, Sep 14, 2012 at 05:23:16PM -0600, Eric Blake wrote:
> [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.
Hmm, my understanding of the QEMU flag was different. Based on
the commit message:
spice: adding seamless-migration option to the command line
The seamless-migration flag is required in order to identify
whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
(by default the flag is off).
New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn on this flag.
When this flag is off, spice fallbacks to its old migration method, which
can result in data loss.
This says to me that any libvirt which knows about the new
SPICE_MIGRATE_COMPLETED event, should set the seamless-migration
flag unconditionally, to indicate that it can handle the event
and thus the new migration method. It says nothing about only
setting this flag if the destination QEMU also supports it.
As such, IMHO, we can & should set this flag unconditonally
on all QEMUs we run which support it.
If it turns out that this flag does indeed require that the
destination QEMU also has the same setting, then IMHO this
flag is a fatally flawed design. At time of starting any QEMU
instance, we can't know whether the destination QEMU we want
to migrate to will have the support or not. Compatibility
checks of this kind can only be decided at time the migrate
command is actually issued.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
2012-09-15 15:10 ` 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
0 siblings, 2 replies; 6+ messages in thread
From: Michal Privoznik @ 2012-09-19 13:26 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: libvir-list, Eric Blake, QEMU Developers
On 15.09.2012 17:10, Daniel P. Berrange wrote:
> On Fri, Sep 14, 2012 at 05:23:16PM -0600, Eric Blake wrote:
>> [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.
>
> Hmm, my understanding of the QEMU flag was different. Based on
> the commit message:
>
> spice: adding seamless-migration option to the command line
>
> The seamless-migration flag is required in order to identify
> whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
> (by default the flag is off).
> New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn on this flag.
> When this flag is off, spice fallbacks to its old migration method, which
> can result in data loss.
>
>
> This says to me that any libvirt which knows about the new
> SPICE_MIGRATE_COMPLETED event, should set the seamless-migration
> flag unconditionally, to indicate that it can handle the event
> and thus the new migration method. It says nothing about only
> setting this flag if the destination QEMU also supports it.
> As such, IMHO, we can & should set this flag unconditonally
> on all QEMUs we run which support it.
>
> If it turns out that this flag does indeed require that the
> destination QEMU also has the same setting, then IMHO this
> flag is a fatally flawed design. At time of starting any QEMU
> instance, we can't know whether the destination QEMU we want
> to migrate to will have the support or not. Compatibility
> checks of this kind can only be decided at time the migrate
> command is actually issued.
>
>
> Daniel
>
>From my investigation I was able to migrate between qemu where one had
seamless_migration=on and the other one didn't support such argument at
all. Literally, on source I've checked out 27af778828db9 (the last
commit in Yonit's patchset) on destination f5bb039c6d97e (the last
before the patchset). Then I've migrated and receive both event and flag
set in query-spice response. So I guess the design is okay.
Having said that - what's desired solution here? Unconditionally set
seamless_migration=on on enough new qemu and don't expose it in XML at all?
Michal
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
2012-09-19 13:26 ` Michal Privoznik
@ 2012-09-19 14:21 ` Daniel P. Berrange
2012-09-19 14:25 ` Daniel P. Berrange
1 sibling, 0 replies; 6+ messages in thread
From: Daniel P. Berrange @ 2012-09-19 14:21 UTC (permalink / raw)
To: Michal Privoznik; +Cc: libvir-list, Eric Blake, QEMU Developers
On Wed, Sep 19, 2012 at 03:26:49PM +0200, Michal Privoznik wrote:
> On 15.09.2012 17:10, Daniel P. Berrange wrote:
> > On Fri, Sep 14, 2012 at 05:23:16PM -0600, Eric Blake wrote:
> >> [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.
> >
> > Hmm, my understanding of the QEMU flag was different. Based on
> > the commit message:
> >
> > spice: adding seamless-migration option to the command line
> >
> > The seamless-migration flag is required in order to identify
> > whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
> > (by default the flag is off).
> > New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn on this flag.
> > When this flag is off, spice fallbacks to its old migration method, which
> > can result in data loss.
> >
> >
> > This says to me that any libvirt which knows about the new
> > SPICE_MIGRATE_COMPLETED event, should set the seamless-migration
> > flag unconditionally, to indicate that it can handle the event
> > and thus the new migration method. It says nothing about only
> > setting this flag if the destination QEMU also supports it.
> > As such, IMHO, we can & should set this flag unconditonally
> > on all QEMUs we run which support it.
> >
> > If it turns out that this flag does indeed require that the
> > destination QEMU also has the same setting, then IMHO this
> > flag is a fatally flawed design. At time of starting any QEMU
> > instance, we can't know whether the destination QEMU we want
> > to migrate to will have the support or not. Compatibility
> > checks of this kind can only be decided at time the migrate
> > command is actually issued.
> >
> >
> > Daniel
> >
>
> From my investigation I was able to migrate between qemu where one had
> seamless_migration=on and the other one didn't support such argument at
> all. Literally, on source I've checked out 27af778828db9 (the last
> commit in Yonit's patchset) on destination f5bb039c6d97e (the last
> before the patchset). Then I've migrated and receive both event and flag
> set in query-spice response. So I guess the design is okay.
>
> Having said that - what's desired solution here? Unconditionally set
> seamless_migration=on on enough new qemu and don't expose it in XML at all?
Yes, that's my desired impl.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
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
1 sibling, 1 reply; 6+ messages in thread
From: Daniel P. Berrange @ 2012-09-19 14:25 UTC (permalink / raw)
To: Michal Privoznik; +Cc: libvir-list, Eric Blake, QEMU Developers
On Wed, Sep 19, 2012 at 03:26:49PM +0200, Michal Privoznik wrote:
> On 15.09.2012 17:10, Daniel P. Berrange wrote:
> > On Fri, Sep 14, 2012 at 05:23:16PM -0600, Eric Blake wrote:
> >> [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.
> >
> > Hmm, my understanding of the QEMU flag was different. Based on
> > the commit message:
> >
> > spice: adding seamless-migration option to the command line
> >
> > The seamless-migration flag is required in order to identify
> > whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
> > (by default the flag is off).
> > New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn on this flag.
> > When this flag is off, spice fallbacks to its old migration method, which
> > can result in data loss.
> >
> >
> > This says to me that any libvirt which knows about the new
> > SPICE_MIGRATE_COMPLETED event, should set the seamless-migration
> > flag unconditionally, to indicate that it can handle the event
> > and thus the new migration method. It says nothing about only
> > setting this flag if the destination QEMU also supports it.
> > As such, IMHO, we can & should set this flag unconditonally
> > on all QEMUs we run which support it.
> >
> > If it turns out that this flag does indeed require that the
> > destination QEMU also has the same setting, then IMHO this
> > flag is a fatally flawed design. At time of starting any QEMU
> > instance, we can't know whether the destination QEMU we want
> > to migrate to will have the support or not. Compatibility
> > checks of this kind can only be decided at time the migrate
> > command is actually issued.
> >
> >
> > Daniel
> >
>
> From my investigation I was able to migrate between qemu where one had
> seamless_migration=on and the other one didn't support such argument at
> all. Literally, on source I've checked out 27af778828db9 (the last
> commit in Yonit's patchset) on destination f5bb039c6d97e (the last
> before the patchset). Then I've migrated and receive both event and flag
> set in query-spice response. So I guess the design is okay.
Oh, BTW, when you tested did you have an actual SPICE client connected
and did it migrate ok ?
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics
2012-09-19 14:25 ` Daniel P. Berrange
@ 2012-09-19 16:13 ` Michal Privoznik
0 siblings, 0 replies; 6+ messages in thread
From: Michal Privoznik @ 2012-09-19 16:13 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: libvir-list, QEMU Developers
On 19.09.2012 16:25, Daniel P. Berrange wrote:
> On Wed, Sep 19, 2012 at 03:26:49PM +0200, Michal Privoznik wrote:
>> On 15.09.2012 17:10, Daniel P. Berrange wrote:
>>> On Fri, Sep 14, 2012 at 05:23:16PM -0600, Eric Blake wrote:
>>>> [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.
>>>
>>> Hmm, my understanding of the QEMU flag was different. Based on
>>> the commit message:
>>>
>>> spice: adding seamless-migration option to the command line
>>>
>>> The seamless-migration flag is required in order to identify
>>> whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
>>> (by default the flag is off).
>>> New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn on this flag.
>>> When this flag is off, spice fallbacks to its old migration method, which
>>> can result in data loss.
>>>
>>>
>>> This says to me that any libvirt which knows about the new
>>> SPICE_MIGRATE_COMPLETED event, should set the seamless-migration
>>> flag unconditionally, to indicate that it can handle the event
>>> and thus the new migration method. It says nothing about only
>>> setting this flag if the destination QEMU also supports it.
>>> As such, IMHO, we can & should set this flag unconditonally
>>> on all QEMUs we run which support it.
>>>
>>> If it turns out that this flag does indeed require that the
>>> destination QEMU also has the same setting, then IMHO this
>>> flag is a fatally flawed design. At time of starting any QEMU
>>> instance, we can't know whether the destination QEMU we want
>>> to migrate to will have the support or not. Compatibility
>>> checks of this kind can only be decided at time the migrate
>>> command is actually issued.
>>>
>>>
>>> Daniel
>>>
>>
>> From my investigation I was able to migrate between qemu where one had
>> seamless_migration=on and the other one didn't support such argument at
>> all. Literally, on source I've checked out 27af778828db9 (the last
>> commit in Yonit's patchset) on destination f5bb039c6d97e (the last
>> before the patchset). Then I've migrated and receive both event and flag
>> set in query-spice response. So I guess the design is okay.
>
> Oh, BTW, when you tested did you have an actual SPICE client connected
> and did it migrate ok ?
That's correct.
Michal
>
> Daniel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-19 16:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 ` [Qemu-devel] [libvirt] [PATCH v2 1/4] config: Introduce <migration> for SPICE graphics Eric Blake
2012-09-15 15:10 ` 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
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).