>>>>> "CC" == saint <saint@xxxxxx> writes:
>>>>> "CC" == saint <saint@xxxxxx> writes:
CC> I can livemigrate w/o problems between any two from red9, red10
CC> and red11, I can livemigrate from either red9, red10 or red11 to
CC> red3 but I can't livemigrate to any other blade from red3.
I TCP-dumped the dialog from both a succesful and a failed migration
(as I said, I have a couple of problematic hosts and other perfectly
working ones).
When the migration succeeds, I have data transmitted to TLS port on
the target machine and to one of the ports that must be open for
migration with this pattern:
first data are sent to the TLS port, then to the other port (and the
communication ends with a reset), then other data ended by a FIN to
the TLS port on the target machine. The reply to the FIN is a RESET.
I checked, it is not a problem with the certificates: I had a machine
raising such problems because had the clock set to before the
beginning of the vvalidity of the client certificate.
I checked libvirtd configuration, and got nothing strange.
The machine that fails to migrate can contact the intended target:
virsh -c qemu://remotehost/system list --all
works perfectly.
I think I am going to fill a bug report...
--
ing. Gian Uberto Lauri
Ricercatore / Reasearcher
Divisione Ricerca ed Innovazione / Research & Innovation Division
GianUberto.Lauri@xxxxxx
Engineering Ingegneria Informatica spa
Corso Stati Uniti 23/C, 35127 Padova (PD)
Tel. +39-049.8283.538 | main(){printf(&unix["\021%six\012\0"],
Fax +39-049.8283.569 | (unix)["have"]+"fun"-0x60);}
Skype: gian.uberto.lauri | David Korn, AT&T Bell Labs
http://www.eng.it | ioccc best One Liner, 1987
