On Tue, Oct 29, 2024 at 10:20:24AM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé writes:
>
> > On Fri, Oct 25, 2024 at 02:43:06PM +0100, Daniel P. Berrangé wrote:
> >>
> >> The migration QAPI design has always felt rather odd to me, in that we
> >> have perfectly good commands "migrate" & "mi
On Tue, Oct 29, 2024 at 10:20:24AM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé writes:
>
> > On Fri, Oct 25, 2024 at 02:43:06PM +0100, Daniel P. Berrangé wrote:
> >>
> >> The migration QAPI design has always felt rather odd to me, in that we
> >> have perfectly good commands "migrate" & "mi
Daniel P. Berrangé writes:
> On Fri, Oct 25, 2024 at 02:43:06PM +0100, Daniel P. Berrangé wrote:
>>
>> The migration QAPI design has always felt rather odd to me, in that we
>> have perfectly good commands "migrate" & "migrate-incoming" that are able
>> to accept an arbitrary list of parameters
On Fri, Oct 25, 2024 at 02:43:06PM +0100, Daniel P. Berrangé wrote:
>
> The migration QAPI design has always felt rather odd to me, in that we
> have perfectly good commands "migrate" & "migrate-incoming" that are able
> to accept an arbitrary list of parameters when invoked. Instead of passing
>
Dst qemu then accepts and reads the
> > > > > migration
> > > > > channel.
> > > > >
> > > > > We need a way to send monitor commands that set dst migration
> > > > > capabilities,
> > > > > before src qem
> > > > Regarding: "what you want is effectively to execute monitor commands
> > > > from the migration stream"
> > > >
> > > > That is not the goal of this series. It could be someone else's goal,
> > > > when
> > &g
oal, when
fully developing a precreate phase, and in that context I understand and
agree with your comments. I have a narrower immediate problem to solve,
however.
For CPR, src qemu sends file descriptors to dst qemu using SCM_RIGHTS over
a dedicated channel, then src qemu sends migration state
24 at 05:16:14PM -0400, Steven Sistare wrote:
> > > > >
> > > > > Regarding: "what you want is effectively to execute monitor commands
> > > > > from the migration stream"
> > > > >
> > > > > That is not the goal of
nitor commands
from the migration stream"
That is not the goal of this series. It could be someone else's goal, when
fully developing a precreate phase, and in that context I understand and
agree with your comments. I have a narrower immediate problem to solve,
however.
For CPR, src
> > > from the migration stream"
> > >
> > > That is not the goal of this series. It could be someone else's goal,
> > > when
> > > fully developing a precreate phase, and in that context I understand and
> > > agree with your commen
On Thu, Oct 24, 2024 at 05:16:14PM -0400, Steven Sistare wrote:
>
> Regarding: "what you want is effectively to execute monitor commands
> from the migration stream"
>
> That is not the goal of this series. It could be someone else's goal, when
> fully developi
can issue query-migrate to get the socket-address for
dynamically allocated port numbers during precreate.
In this series QEMU passes through and does not linger in the precreate
phase, and the user sees no change in behavior. The cpr-transfer series
will linger in the phase for an incoming CPR
On 10/21/2024 3:20 PM, Peter Xu wrote:
On Thu, Oct 17, 2024 at 08:14:14AM -0700, Steve Sistare wrote:
Guard against unconfigured state if cleanup is called early, such as
during the precreate phase.
Signed-off-by: Steve Sistare
Reviewed-by: Peter Xu
One nitpick..
---
net/net.c | 4
ddress for
dynamically allocated port numbers during precreate.
In this series QEMU passes through and does not linger in the precreate
phase, and the user sees no change in behavior. The cpr-transfer series
will linger in the phase for an incoming CPR operation, and exit the phase
when the migrate
Steve Sistare writes:
> Refactor qemu_init into actions performed during the precreate phase,
> and actions performed when exiting precreate. For now, always exit
> the precreate phase immediately at init time. Future patches will add
> conditions that cause QEMU to linger in t
On Thu, Oct 17, 2024 at 08:14:14AM -0700, Steve Sistare wrote:
> Guard against unconfigured state if cleanup is called early, such as
> during the precreate phase.
>
> Signed-off-by: Steve Sistare
Reviewed-by: Peter Xu
One nitpick..
> ---
> net/net.c | 4 +++-
> 1 file
MU command line or from a migrate_incoming command.
Thus the user can issue query-migrate to get the socket-address for
dynamically allocated port numbers during precreate.
In this series QEMU passes through and does not linger in the precreate
phase, and the user sees no change in behavior. The cp
which can come
> > from either the QEMU command line or from a migrate_incoming command.
> > Thus the user can issue query-migrate to get the socket-address for
> > dynamically allocated port numbers during precreate.
> >
> > In this series QEMU passes through and does
cc jason.
The cover letter for this series is here:
https://lore.kernel.org/qemu-devel/1729178055-207271-1-git-send-email-steven.sist...@oracle.com
- Steve
On 10/17/2024 11:14 AM, Steve Sistare wrote:
Guard against unconfigured state if cleanup is called early, such as
during the precreate
et-address for
dynamically allocated port numbers during precreate.
In this series QEMU passes through and does not linger in the precreate
phase, and the user sees no change in behavior. The cpr-transfer series
will linger in the phase for an incoming CPR operation, and exit the phase
when t
Guard against unconfigured state if cleanup is called early, such as
during the precreate phase.
Signed-off-by: Steve Sistare
---
net/net.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/net.c b/net/net.c
index d9b23a8..207fdb0 100644
--- a/net/net.c
+++ b/net/net.c
Refactor qemu_init into actions performed during the precreate phase,
and actions performed when exiting precreate. For now, always exit
the precreate phase immediately at init time. Future patches will add
conditions that cause QEMU to linger in the precreate phase while running
the main loop
ers during precreate.
In this series QEMU passes through and does not linger in the precreate
phase, and the user sees no change in behavior. The cpr-transfer series
will linger in the phase for an incoming CPR operation, and exit the phase
when the migrate command is send to source QEMU and causes d
On Thu, Oct 10, 2024 at 11:19:15PM +0200, Paolo Bonzini wrote:
> Moving migration_object_init() earlier sounds like a good idea anyway!
I take the last sentence back of my other reply - I believe I
underestimated the potential reviewers of the upcoming precreate
patchset.. :)
--
Peter Xu
now if you think this is the right
solution, and I will revive it.
Preview:
0725d70 vl: precreate phase
edd2dee net: cleanup for precreate phase
4733c00 accel: encapsulate search state
6d26ea4 accel: accel preinit function
518e737 accel: split configure_accelerators
8ef936b acc
there a branch we could skim somewhere?
Yes a tree can be clearer, with an example usage.
This design looks even cleaner to me (but maybe misunderstood some part),
it may slow down the merge because we need broader reviews. So it's just
that it might have higher chance miss 9.2.
>
> &
ght
> solution, and I will revive it.
Seems reasonable to me, given the requirements we're working with. Was
there a branch we could skim somewhere?
>
> Preview:
>
>0725d70 vl: precreate phase
>edd2dee net: cleanup for precreate phase
>4733c00 accel: encap
o I need
a few days to rebase it and test. It is not small, and requires approvals
from additional maintainers. Let me know if you think this is the right
solution, and I will revive it.
Preview:
0725d70 vl: precreate phase
edd2dee net: cleanup for precreate phase
4733c00 accel: encapsul
28 matches
Mail list logo
