On Thu, Jun 30, 2011 at 10:22:59AM -0600, Eric Blake wrote:
On 06/30/2011 10:10 AM, Daniel P. Berrange wrote:
> The virDomainMigratePrepareTunnel3 impl in the remote driver
> was using the procedure number for the virDomainMigratePrepareTunnel
> method. This doesn't work out so well, because it makes the server
> ignore & drop all stream packets
>
> * src/remote/remote_driver.c: Fix procedure for PrepareTunnel3
> ---
> src/remote/remote_driver.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
> index ce9bcb1..f318740 100644
> --- a/src/remote/remote_driver.c
> +++ b/src/remote/remote_driver.c
> @@ -3691,7 +3691,7 @@ remoteDomainMigratePrepareTunnel3(virConnectPtr dconn,
> memset(&ret, 0, sizeof(ret));
>
> if (!(netst = virNetClientStreamNew(priv->remoteProgram,
> - REMOTE_PROC_DOMAIN_MIGRATE_PREPARE_TUNNEL,
> +
REMOTE_PROC_DOMAIN_MIGRATE_PREPARE_TUNNEL3,
ACK (and how did we let that bug get in?).
I don't really know. This is covered by my huge migration test suite.
I can only assume I didn't test the right combination of client,
source libvirt, destination libvirt, because it only occurs if all
three are on v3 protocol.
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 :|