On Wed, 16 Jun 2010 21:10:04 +0200 Juan Quintela <quint...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> wrote: > > On Tue, 15 Jun 2010 17:24:59 +0200 > > Juan Quintela <quint...@redhat.com> wrote: > > >> > > >> > I still don't see the need for MIGRATION_STARTED, it could be useful in > >> > the target but I'd like to understand the use case in more detail. > >> > >> At this point, if you are doing migration with tcp, and you are putting > >> the wrong port on source (no path or any other error), you get no info > >> at all of what is happening. > > > > Shouldn't the migrate command just the return the expected error? > > No. Think you are "having troubles". You try to find what happens. > launch things by hand. And there is no way to know if anybody has > conected to the destination machine. Some notification that migration > has started is _very_ useful. expecially when there are > networks/firewalls/... in the middle. [...] > That is it. But you continue telling that going to the old house and > doing a info migrate is a good interface. I'm sorry? When did I ever claimed such a thing? First point: all you describe is MIGRATION_CONNECTED, at the end of the day it would do exactly what you want for MIGRATION_STARTED. The second, and most important point, is that we're trying not to make things worse. Adding a number of events to circumvent a bad designed command and having the wrong expectations (ie. help developer debugging) is a clear recipe for disaster. Anyway, I think it doesn't matter anymore, as QMP is not going to be declared stable for 0.13. In this case we'll have enough time to design the proper interface. > To add insult to injury, the problem is that libvirt people are not > collaborative, and expect things that can't be done, are uncooperative, Again, I've never claimed that and I think you're taking this thread to the wrong direction. > .... > > Libvirt folks "also" do lots of things wrong, they are not perfect. But > it in this case, who is being completely unreasonable is qemu land. > > Later, Juan. >
