On Wed, Mar 9, 2011 at 9:47 AM, Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx> wrote: [snip] > Or something related with firewall perhaps. > Can I stop firewall at all and have libvirtd working at the same time > to test ...? > I know libvirtd puts some iptables rules itself.. > > Gianluca > OK. It was indeed a problem related to iptables rules. After adding at both ends this rule about intracluster network tcp ports (.31 for the other node) I get live migration working ok using clusvcadm command iptables -t filter -I INPUT 17 -s 192.168.16.32/32 -p tcp -m multiport --dports 49152:49215 -j ACCEPT I'm going to put it in /etc/sysconfig/iptables in the middle of these two: -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited I can also simulate the clusvcadm command with virsh (after freezing the resource) with virsh migrate --live exorapr1 qemu+ssh://intrarhev2/system tcp:intrarhev2 otherwise the ssh connection is tunneled through hostname in connection string, but data exchange happens anyway through the public lan (or what hostname resolves to, I suppose). BTW: I noticed that when you freeze a vm resource you don't get the [Z] notification at the right side of the corresponding line, as it happens with standard services... Is this intentional or could I post a bugzilla for it? For a service, when frozen: service:MYSRV intrarhev2 started [Z] [root@rhev2 ]# clusvcadm -Z vm:exorapr1 Local machine freezing vm:exorapr1...Success [root@rhev2 ]# clustat | grep orapr1 vm:exorapr1 intrarhev1 started Cheers, Gianluca -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
