[ClusterLabs] Re: Antw: Re: Antw: Re: Antw: Re: EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Missing link, sorry: [1] http://www.cse.scu.edu/~jholliday/COEN317F04/totem.ppt - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV+EMyAAoJEDg5KY9j7GZY90QP/Re7KZL51ye1RC3DJqQ9mW9O WqIERHhu2np0/uyRjO0MHrOXecPu9z5k0yQzlZZpBwuWlFtqi68ioTS37hJrKQlX 9/Fuo+wdUWCd/MaBHZjOJFKFKq0azNuO5IiulyZD64+NetEbY9mpv8napEpW7CE/ kyxHLXb/qfGXcfS+NMiZMfgAKFd8JPOVBEc1b2vIL2hIoNCKkx4rhMjlrnK6GRQi dfYhTuy0s/5RQRJs7A3+VLa46W4rUx10i8MxPV1TaXz5vb03P8cA5Glg1YRN2ILt LqcNojRFvSfBV7I/0pAshxEUpL+bSdGmLg8Nu5b4ZKvKJoI9bLSTa/8alY5v2nXX IaIrRF6nujphFkf1Km4Qdz1BUBbp7g0ztXct+c2qjCaMgm5b0pO15JEgJy9JJku+ GKKGSEYB31eznsVZ4adVhTidC5jTx/TyfLmv190I5+m6eYSjDxArsXkS6faZrp48 i0kq9QY4stv35feabqbZanqaU5sZmtRpS0daP+VpzZtterEwnmpO1sdwEavhXTp3 /lOlUly3tvzyePIdwJBT3xMZkQ1yQCZ5OD3CRaZqRmLQoldM1ngHfvJ+pgMz9SQJ nsy0HuxDhOJn/7fdnP5QB+b98YVaDAHiqXHGW7NA1q3R3PeyrmMfvpcwCJW2hMjn 3gQXlckc5j9rI70j+v9U =0kHs -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] Re: EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Digimer, > So what's the final verdict on this? I followed your back and forth, and > it sounds like corosync uses 0, so nothing else is to be done? Missing prioritization itself cannot be the cause of the problem. Either some other application puts its packets into band 0 or the cause of the problem is not to be found in this domain. The problem should be reproduced and diagnostics should be done. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV+ELrAAoJEDg5KY9j7GZYyCcP/0YQP1fa7sUOJRefP5C9vsu0 DDIdwBALOaV4yGu3mJMTdSoL7ptd3GPENOLO+M+qXwnmTr4ZZXMp8frRAyaZQhnm TE/q1KSJGPKLwovwU5dATVz60hetgwOxJ0s17eqLJtPOD2xq4WgR74G4gHxTmvRA D+lhhvGrhUKWVLc92GmNU2kN1U8jUU6sxciT7GTVkejvw9Cru8s54xRG2WtpfSIE jW2aillCab194vZzFzsT/nLETh5LNuBbLQftCKfi14z+kZSQ1nZsBmjgP/cQH1To 7f7RiHsLuQZrv74E8rzHObjzAfN+xUsJokxFOFxpdu0Q5DpfAyq/V/OfdPkB4ymd 6e2Y4Rnz/AwoJowUf6l3Ke+R+JYCcS3pw2Io/NRMa7Xh8gtjSYvVTfYr6bAb9T7p Lx91PBjtezHTY9fqQQ1/VRblnxr6o0VFinLxGsOJ6jungk1ieolhYI5EiOzx/rN0 iJiLqUNC9fN9UO0acxNqW+U5/T7Uypj1jsDlhT3Pit+uvpyj4nvlgf2WtHZCl10u enjForcvCMPZZDFZ+5lHOUJkPlIKmbWjm9mXzFUaYsbARRobeIiseH8mfVBG4QZb W5XAuwmLyijfe/x3NCOWT8DkD3VZtaYCEK2sYhfXERg/hzUcJ6yM8d/xJpra6vuG LNS2mMytQxOx7D0noxpj =nP0r -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] Re: Antw: Re: Antw: Re: Antw: Re: EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Ullrich, > If you send a protocol from A to B where neither A's interface nor B's > interface has any errors, and B reports a protocol error, the obvious > conclusion is that the protocol is broken. Es pecially if the protocol claims > to implement reliable in-order transfer. > Of cours from "no interface errors" you cannot deduce "no protocol errors", > but if both parties use the same software, the bad protocol can only come from > the software. Agreed. > NFS over UDP has the feature that it works under load, even if some packets > are dropped. I cannot confirm that property for TOTEM. NFS is for bulk data transfer and has to deal with network saturation. TOTEM isn't designed for this. Taking this from the first link[1]: "The Totem single-ring protocol" *Provides rapid detection of network partitioning and processor failure together with reconfiguration and membership services. This property of TOTEM acts against the desired property of robustness against network problems. I think the TOTEM configuration can be improved against the known problems and sensitivity to datagram losses by increasing the retransmission timeout and threshold. Doing this increases the time it takes for Corosync to detect dead nodes, though. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV+EI8AAoJEDg5KY9j7GZYRwoP/3zwsEjJSk+VBXBq6avMJEch F56oLTScFal/CZ6l1J2fgw68GbfZWOnh1xFfoik8iBH8VEOt9wfow32BlkLmTt4u 8zjyIjOCzTW9jbcebeVYx72SqutdQpCPfR1/D7jQJdHBT6wk6aTornMrpVYGjac7 UyGoUb05nTFaMniNN4T52TkpQJ+/sgwVk68ymIXljcBIcnDh2gbF5cvXXni+KFMW 2J3SjlZm8GvbUhYuW/HGAiRPURgZtvMgTnBAfByUkTTRGiZVGIbRJ4sjJTRdKgQW 4Y3hqjc4o9brLgGr3oiydKo0uvjDOELb6wJMvL1p6BoNgWQ9lI68FZCYEOLa6MOf bXFRIqcaoeoTWuiBdEVydEhsXvr05mYu9hATIf53w9514XQIFSlAFBLPwtXr/OlO e4r6M8avfGsC2FnWp9prHZ5NBJTD6GY3OOpJIprboBGhqTsobRXXFU6DSupHvNtY X0P30o6FjeAEc2l2aZxUp3m5C5L6hQTKioNC4rUG5uGK9fHOR1IX6l1M3Nmf5cxd BdHASF7Eg06pHMUCxQ0jMW3hcHFAJ4aaUDzVzj0nOh77ZfsLeG0+rr+3KO6UmVko GLHquPygFe/S6J6MnZVKiuCMyIrlCORsg2sggELpo8NjKmuuQHWz0eP81PefuCVF cASk6Mfsx8v97iPQUAJG =hSE9 -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Chrstine, > There are other networking scheduling algorithms, I think. Though I > haven't looked at them in detail for years now. Maybe we should > investigate and see if there is one that might be more appropriate? I'd propose recreating the issue first and doing diagnostics on it before poking around in the dark. If it is indeed a prioritization issue, then something else must be in band 0, too, along with Corosync. Otherwise the prioritization cannot be the issue. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV+D+RAAoJEDg5KY9j7GZYWIQQAIzSSPacTofEGfHVtDaHn8ww ahFoplgAP9o6uRDYa/6DlIe23z8NU8HtRjTDjehZA5nkGNqMYYzjBCpTYjCSuXlA A1JC1oovihR8bJLymAsW4+ojlTITRNbJzsh00i2KzGJyIsH79BBdVjeW6Ln5udNy GemU7ttTkgc5kyJJvknPrKV9AmuffRf1l2jbXNTrmHro0Zi0ZhT+XWXO2++NSlWo wliOFKFyCouhtCPpASSgPTXsDhqheEwsDT4DUkPPMpPprsF2LW0bC6qHWGaNFM4g +MkXb+d5aLbS+7wwL0g8wHjOu+RCgMQyvofc6lWYLYiPNjMiAwld29EgAFb3CbuW 7ue65EPhffd7dmVjV0UjpsYouoGug+IzawgRFuJb1jN/ZtQNy7YNDPWkW+/jBz4h 4pOWuwMxrnQSBI41rMnlGYdoSim+zxcdkxsaU6/YgGwwaNedUg74mbf6UNCUyjbv 4vPl3Nx9Hd5zJ2cY7fPWbljXn2xUh/oGBEYn5pbXzjWN47NVH8ESL2CORIaZbrY+ Hb4D0GePJhbn29+2+JsSYkGVmgZb/GakLiF8NnbS57j9uc3DfZIPb+YpMTHlYTXD 2nabljsbHpG/Ng9DKrwnOibrfCOGNEQ+GbVCXJx5y84duczylIU+FvH5IYwnwx+0 C9XL7e9yLXzsSNhO468m =/5Xm -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Re: Antw: Re: EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Ullrich, > What totem does it detect network problems when there are none: > > # grep ringid.*FAULTY /var/log/messages |wc -l > 1981 Yup. What information from your specific setup can you contribute to this particular discussion about Digimer's problem? >> This is something that no other protocol you encounter on the internet/LAN >> is supposed to do. > > Definitely not: 0 interface errors on any interface, not communication > problems. What does protocol error detection have to do with interface errors? Protocol errors aren't contained in interface errors. > Even NFS over UDP is much smarter than TOTEM is. NFS over UDP is for bulk transfer of data. You're comparing apples to bananas. What improvement for TOTEM do you want to take from NFS over UDP? NFS over UDP has congestion control. Is it that what you mean? > If you have a central authority that can decide on each eand every priority > you are right. I was talking from practical experience... In a point-to-point topology, like Digimer is using (host-switch-host), the switch in between basicly guarantees that every valid frame that enters one port also exits another port of the switch. This basicly makes the switch vanish here. It's no longer relevant for this, assuming that it does its job and the switching matrix can handle the frames, which it probably does. If it can not do that, then the switch should probably be replaced. The remaining two points are the interfaces of the hosts. Digimer uses bonds. So we have two interfaces on either side. The interfaces themselves do not do any prioritization. They just pass valid frames through to the OS over interrupts. The central points now are the bonding devices, which have traffic congestion control algorithms attached to them, too. Not for ingress, because Linux can't do it, but for egress. The egress, as I deducted in other emails, is fine. The pfifo_fast qdisc is the central point. There's nothing else in this architecture that influences the transmission between the two points. Of course, this model is idealized. Maybe there are outside factors that cause the problems, maybe there are not. This is something I cannot know about this setup. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9uvuAAoJEDg5KY9j7GZYf94P/2LjVa7+L4+VheXnUjG6s4bG zE8tWte/ZGHyijJsF/hrA2WgBQJAbaYrcwCC3e0aJpwRwocsggkUfbhdffrZ1CGs D7s56ELTNZP8cL19T5VtVB/Ki5A7G8zzdqDmq7lo+/H3maH9Ffhl0AKvXCFM5g/L c2EK3Mnc2vT5uXkfVwKeJAATmD3pFh9GFKkyLCwYOTL0e1t1VO6ZyyHGwMHDLkwg pcHMxWlEkHfq+L94Fk6Tba6POJAVwOh3F3Q2DnKtot7+w4lNo4bPN2xZNGqvKRU5 75WOsOfgGTC39qEJ0dMv7gA2GxX4J4l909Cj9StVX63GpbXqfQ+d+s5LwzXw8tiJ aIeqlo6BegAF2/qsJZXT6dP0ofRTEkb0KAzUM1S4TaDaQM4MkFJgDCRlDiBJc+U6 j9D8fLd0c8Dm8Yn7GOvix4GwQPkcZV6RSOI5ErZtDlEGfI+ctRcfiIsoHqtFwHZJ 8mzlqu4etGKEMDJAfhR44z3Ui0TCGk8y/eMV0ZldyBblRNth7gDJ1r/1IFpQuTWi xK39ri6ow5CMdTeTqQKu4O889bbYyOZ22hXSBCkHbmtvFK2cec4wqd6f5iEsxY49 hvqIlw4ls+B9Eh+Nvp2jX6O/w47r93rewz6CCnjcA1y9A+DpSMQUCGd6k2znVimy 3tbNOBQCdI5lKULqVMIU =d5MI -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Christine, I googled a bit and some doc[1] says that TC_PRIO_INTERACTIVE maps to value 6, whatever that is. Assuming that value of 6 is the same as the "priority value", Corosync traffic should go into band 0, because TOS values of 0x10 and 0x14 have "priority value" 6, too. The page[2] on lartc.org says that, too. That means that at least when pfifo_fast is used, there's no need for iptables rules or tc filters to prioritize Corosync traffic manually. [1] http://linux-tc-notes.sourceforge.net/tc/doc/priority.txt [2] http://lartc.org/howto/lartc.qdisc.classless.html#AEN658 - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9t2yAAoJEDg5KY9j7GZYA88P/3RVecICvk8PPSkP00SzUwB4 Rz1UCPyrT68y0ndvxWo9XL4aVBjKskmFHCD6db74hn6LOwa91l0lgV/ii6CZWHge 2Bvp3TVM18BzWN/iy+4AbAKHQ8wayLH/c1P1lRy8BYDCVvLK8/hT36A8TOPYhCFa cXQcD1cGfAbfTlFTc1UjuJRjniPA8SOwHtbRNfSdJw6PznYX7smGy3tfcu7bpGRe 6Q62eaayZn1P3tZb3yc1Jt/J237pf9GMBCqLu6SRg0+yKJpgyhfSBgMtg7rCrPP3 ax6ta6ypXgIucCgp68vo78k1hcXwIDmUbvkuaR+su0GTulFIhl6qh74l+3UDFISH hICNa0TdznFX0JHy3hsko+W97zC5ywMNCm/RTiy6DckHnshZyuLS5G1gh50AGhgc tGMn1K06fIqmpq+MogRvZeszNOqm43qTBGGD1oXYOIcJnBbIYuUevLs5xoKWkwS8 afqvIWjFeNIKkEDjla8h9RblpzLAZ8uR68m2jYrev81Bb14DqUnVb2m3DcbqwYIS x7wtoY4Mxj3c4joH+xiJ/Hk2JXf+S2JqoDFwcyLoh3gfAle7YAhx9cl93xCjJgf5 7CsTrojhRyLgOcvFnMpCB6r6guNVGqFN4kUvgP7eMWxBLpEE53CS4V44YS1QJkGR 6z+6w1a02L2UAgVI16Oj =Q8Dc -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Christine, Do you have a pointer for me where to look in the source? Searching for TC_INTERACTIVE in the Corosync sources on Github yielded no results. How the scheduler handles the packets depends on the settings and type of it, so yes, it's no guarantee. Whatever comes in front of the scheduler is important, too, but I do not know if there is something in front of it and it it is, what it is. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9tigAAoJEDg5KY9j7GZYzG8QAJq0a47VlmpJQS0fAnXkW+1f ejTX5FX5tKotHQHRIBnp+mImH8JzSd2z0Al45w+dy99a22Usx9VGvzwyOt4nSSJj B6Nh3CEZRJuGq4CnUM7qS3WP9ZF6m3R+5mbvDAl/CNRjkFDRbdxrjmpAYbcwJu+A Pjeo5DtN1jwwZVZvUDRYRcguiJ0FY0SfQxgegvfJohSw58KEDcvVoUUFxVMcyJcZ llpmp3fB3pe2KpsDPQobsfw36BGEtkOd4dHd+KGMvWHXQxtEwh5HXoCSu9G8ztey 51b34KKsi3a1pOet8gXWDECiAeOPX31PnjBCAF/bzy+xdkqyX9dH+LzUaLhgkCSy Zd2WJPOPQxob6SXLT4Nwi1uWoFSyHjPMILUStGRvIQt1520r6tQeXuxnFOnyohv4 AXYgEjeXLvJ3Dm5kCp/esPOJTxK0tMm4G1gtjCY3B1cGda/sAtDI3y5Xh4g8FiYE qtHyJ66c3wkKMA2myT4ZiklNf6Gdk1iGgIbSfoMdsYu4GrDVz0oMKyalE6OIvWfM lZrqS01ruXf3heT753UB9g079xcs0Ofuj4SmkD/3FPPAAzAcDac8VXPVW5Coktzf NutX+mfW/YRM4TmKetOLx8CicfLDgx4lGo8AAXyNLAxIE0yZf1czoar0aViizRZz bOvRvU4SZ2b7hrWfEcM7 =XBBE -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Re: EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Ullrich, > Actually I don't understand that claim: If packets are delivered in order >(mostly), any TOTEM packet has the same change to arrive than any other packet. > While all other communication protocols can actually deal with Ethernet and > the > Internet, TOTEM is the only protocol that can fail even in a switched LAN. I > haven't benn convinced yet that it's not an implementation issue of TOTEM. > Instead of telling people to fiddle with their network configuration, I'd > prefer putting more efforts into fixing TOTEM. I assume with "change to arrive", you mean delay? Or do you mean the ordering of the packets? Totem behaves like it does because it needs to detect a failed node, afaik. This is something that no other protocol you encounter on the internet/LAN is supposed to do. All of those protocols are either for error reporting (ICMP) or for transceiving of data (udp/tcp). UDP obviously has no congestion algorithm, but TCP does. > The main problem with priorities is who decides what is most important, > especially if a medium is shered by many different software stacks and > applications. Obviously some type of prioritzation has to be done, or at least should be done, because some things *are* more important than others. The only thing that can control congestion centrally in a computer system is the interface that controls access to it, so it's either the NIC or the software that controls access to it, so the network stack of the operating system. The problem is a different one when the LAN is bridged, rather then switched, because then the transmission of other hosts affects the transmission of one host. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9rWvAAoJEDg5KY9j7GZY3LkP/3vkEppL48nwlAGVpFIbVIRj HpC6usWTFTaS3s20FOBo+60mtGAi6QnDku05WEkcjKrN8rjb0lll8KKAxCAP5ejO xofUpmSZp4vs534gpwYotXf8IU4ZwLsF5WEjdtVc0AoVk99TNwS8g7P2eGRybvxy Qdr+C2I99n4iqr93MRjDRRZj5S6t+PICr7s2hRrGrNIiSO0XJJdnoJWYR2g3DlPi 9tw2nyb832Pe3eusRqBdXN1lDEw8Amr2apjW6yGlNKlbaVe/TbcxZg4qnuPQtTAa Jc9pxItG31ZGG6G3SyzQuU2VG1DUGfyqUBAKv//oQtlb8YEklYHfzvhUvf4/XTJn 5Zcv6IVoTUVVexB6bmQ6sHxbsXpHrb7Y+uViqVNEogJ66I4kTi9jo7DxxW3Mjsct TSMjGAWEdmhi1KKONuCnqLMvyVdqdF/4VKZhJ6P2NaVQpk/8zXXrp1Q0zJmfupV6 awQXvwRdAwM4KP+G94KxjFn8J7cuC3a6Hk2LuQp2OL/2IEliN5p8+R0lii6eVev4 n+wVsgLve/JHMBghNhJTf5Fs6+lUsgOOYt4RK3/gqAFuktE53XqmwdMVjl3yelXR UR5J3GxQ5AbuhzetbVn1HIVMfOzwjzgW8vjcWmkmB01tOKXyvpyWRjFP6HawLxCh kWHwsh6S+7OxJ0Oijrs5 =CyyI -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Christine, > I think it's worth mentioning here that corosync already sets its > packets to TC_INTERACTIVE (which DLM does not), so they should not need > too much messing around with in iptables/qdisc If that is the case, then why do the totem messages timeout? Corosync is already running with realtime priority and its packets are delivered instantly, because they get put into band 0. So what's the problem here then, if it's not too much traffic? Do you have an idea? - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9rNPAAoJEDg5KY9j7GZYoukQAJbGYCMeL77F+v5ynRGuZoCZ +8XttYNzzZKMdHGnMcO8ewzOBjPKcYkl+KLe3cT/Mnpgt5RWqONwh3r7aIMK4NjQ inhV5xpdW3JfPP6SCVjc5GoO8L7QmIKPKjhMaWPXw0E5eaW+7u1fVuiv6Cqshucr XAfEq3lmETvRh9qSphVLPL7ay5/V6AUBpwV5ThRkXGXammA9b82v5PDyeJOOmmve zTyeybRCcIKYmPciThA9W0GmJJjVzqwVCBd3vX79+s+m/DlEh1wCcmiUQtD4hNnT NNQ4TnvGk5TzerEDCd+BhJWQU6IOwtCCDVE+injDZ7fbF7e8IpRh/h+y2QytF7aM NZmLELV9W9QCNZN1B8xvMOEoR31bqTcbDCrocEDjP9QHfaCpDJ8uRDInEK81fNe/ ARFV6w+k6A/j45R4qCfAdJf0T5XXvjugOEZO95q4yNIc/5TcDIDi4GuJ6+pGNhQR VyJKi06OKJ2oSvpwPnJ2OGghXwkVxNqFzFOBAVWMJ7O32hLK8wRvTR4PF7Mbep6z JYw8DvbnWi1mAAhxMa2TgeFHSxQ6sU+CslUIrTA53qTKd/Fu6+SHqyoiPAfItHUB lGvVJMsyo1Cgtauk0yzpVAJbK+3Y36/rfVsatTGHfWWFyBX3+ZpP0yrtBtgt+dkv VqC0hELMsjZ4X6clHwUA =HDmX -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Re: EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Ullrich, > Then that's not FIFO, but priority scheduling. Eveybody knows the starvation > problem of priotity scheduling. It's mixed. The individual bands behave like a FIFO. The bands are prioritized over each other. > Imagine some cluster filesystem has it's own timeount / fencing mechanism. > Then TOTEM when going wild can cause starvation of other services. It's the > wrong design IMHO. > I wonder whether this can explain the mysterous cLVM retransmit list growing > under some loads. > > [...] It can, if the total bytes in the queue is higher than the transmission rate of the network interface. Packets in band 1 and 2 are only not delivered if band 0 always has packets. But again, for that, the transmission rate must be lower than the rate at which the queues grows. Does totem generate a runaway stream of packets when they are delivered in time? - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9rJNAAoJEDg5KY9j7GZYTGkP/A/WN+7NR5RFV9BXXRyircQ5 jNBkBoFKvhkyts5Yr9KUnnghlG/Kov+iPAYBaOpf8CRuo5PI0jN7UUjSYmg65GsM rJFaWr+zPvIftrNc+rhT9ID2g+1OKQSbCGdnq6MjPbuLpoU3b9153J4wb85Qjf7B OD5+rmtlvPFswvfwbXN+Q6pS+GOovZThad08PQQCNfNqqzda/wlnxRxLQSVywIWS MV0M7ciwmsnlbnmIamp4fSepwtJMp1dw+eprcGOKCCVnSzzPIfG6ZSZv5m737+KP TfpqTdkEcF9xUk2mmd4NPSX7FmW0djKy1Ws2gR26j5l2332lcc29E7tItV18Lr8J 6se0oNdXXWcjL1dfIkS0wox91eZBMH6RpQWuIBiYzN+y21VzU1ycMoiwlMTI4vxo GTlqX51dB+IZ+FZ0Tn2UPmzWuz0oAQ3PEIZUD50KgOLELLp9Ri2Fpy4CKrJv2k6O 9fb4dq1vPvBiMthYUQ75Y/zb3YSteA2gp7VpSYQUEtfsJdwf6oS2xefIa0vqG232 9K76Wf5EJFw3hKy3guAsv3Sc7K8Bo3rqpnsyFyJmk2Xq5iticZGdgSZYp3xg1mP6 UjdGH9ic+7KKFPMh4Y6e0VO2NXOAuYX2AelHyujHfK71AVbri+IfoMJrJszIISwT xxJV7KsfaQvGo+qRlAzq =qEtz -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Digimer, > I am a strong believer in "keep it as simple as possible". In a case > like this, it's hard to argue that any option is simple, but given that > RRP is baked into the HA stack, I decided to trust it over QoS. I am > perfectly open to contrary ideas though. Can you help me understand why > you think tc's additional complexity is worth it? I'm willing to fully > believe it is, but I want to understand the pros and cons first. If you want or not, the kernel always has a queuing policy on any network device. On CentOS 7, it's a pfifo_fast[1][2] queue, which is a classless fifo queue, but with 3 bands (0,1,2). Bands with lower numbers have priority over higher numbers. As long as packets are in band 0, band 1 won't be worked upon and so on. The band a packet gets put into depends on the TOS/DSCP mark on the packet (TOS and DSCP use the same field in an IP packet. They're just different standards for the values in it). The TOS/DSCP field of applications that don't set a specific value for that on the network socket they use (SSH can do that using the IPQoS[3]). So obviously, by influencing the TOS/DSCP field value with iptables, we can influence what packets get send out when. The goal here is to prioritize Corosync totem traffic (UDP port 5404 and 5405) with the correct TOS/DSCP value, so it ends up in band 0 and all the other stuff in band 3. This leaves you the option to put dlm traffic into band 2. The priority would thus be: totem > dlm > migration As pfifo_fast maps different priorities into different bands based on the priomap, it must be looked at to figure out what TOS/DSCP value must be set. The second table on the linked LART article[2] gives you the priorities and what bands they're mapped to. It tells us that TOS values from 0x10 to 0x16 are mapped to band 0. So we need to set Corosync traffic to that TOS value. DLM must be set to a value that maps to band 1 and so on. AFAIK, the TOS target in iptables is a non-terminating target, so packets that matched the rule continue to traverse through the chain. We don't want that here, because it will screw with our prioritization order. So we ACCEPT traffic that we TOS'ed. Example iptables rule: iptables -t mangle -A OUTPUT -p udp -m multiport --dports 5404,5405 -j TOS --set-tos 0x10 iptables -t mangle -A OUTPUT -p udp -m multiport --dports 5405,5405 -j ACCEPT iptables -t mangle -A OUTPUT -p sctp -j TOS --set-tos 0x18 iptables -t mangle -A OUTPUT -p sctp -j ACCEPT iptables -t mangle -A OUTPUT -j TOS --set-tos 0x8 (The default policy of *mangle OUTPUT is ACCEPT, so there's no need for an additional rule at the end to accept the rest) Tadaa. [1] [root@c7-arch-mirror-1 ~]# cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) [root@c7-arch-mirror-1 ~]# tc qdisc qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 [2] http://lartc.org/howto/lartc.qdisc.classless.html#AEN658 [3] `man ssh_config`, search for IPQoS - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9GvAAAoJEDg5KY9j7GZYhbAP/j69CfA24ZKVBwdsgNjrSpQ7 NBJmqncIvYVn1MFfKopJfZvsSOY95IiInWycIJ/CBXEMdcqutWpXyxK9aq3/gnZT OyR1gn8se44ieWa1DrYK8XGhuWqkANXY7c8p3he/lwdGVu74Yg6VGYA5UMkztdit 0RIOmjH/WT5hZLipmSbtA+4g+swhZyEktJUm6slfigqSWYHv8I2kSMXcE1vgXlWp SRKLUhFPEMwPg7l+xsm/Grce1Yf6R4UPN7cxTaWgOg57jq8HljehhdxynTOy7j/3 AGB4nz8rHniW0cVqy2UXSABJc9JiBz59RhTYpj7C3I3lJLLTU2vfhs6IwSKLhnWR Cf1DuF0LOOqYKs+Rr4vw0rqkIn186FVTcVtuIOd3zNm9+yfs3NJFRom3RE4QyTpn taRJd9bsg3N5v4ExMiV6ZvboTJjPMbdZaEl512QpIoctQxHB/4YNsXb+/DINr0zb H5Ec7eEC92X1vfrqufAtY9hB2z43QtKRILdhg0e/1LhjZ5t9N82GwVoaZNxeE/Iq RFv42s7dOOk6QT/2yUl7wSGll6XwPFsHHISszLF8KZBFEXSREikt8mRL0n04vroT ACO5m8cXWgDTMpNiRqN9p5IFHIBabstapZQjH1g1dmExhZZDN8hnO09JMimB8OJj Z5IlRo2R8POif1Ql4/ay =Y/Gl -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] EL6, cman, rrp, unicast and iptables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Personally, I would set filters in tc (packet priorization/shaper part of the network stack) to prioritize Cluster packets. That way, delivery of the packets is basicly guaranteed. I'd do something similiar on the switch to make sure it prioritizes the packets, too. The migration traffic must always have a lower priority than the traffic if cman and the other components, so the totems get delivered in any case. The default queuing behaviour is FIFO. This is obviously not desireable here. If the preset queuing mechanism supports traffic priorization, you can possible get away with a single set of iptables DSCP/TOS rules in *mangle OUTPUT to set the correct value so the queue prioritizes it. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV8yA1AAoJEDg5KY9j7GZY4YAP+gPF8AxWT8PqOOvZviwGf6Sy JCHjZKFYREM0E9MYESLxYmm0Ipvjy1qszJF4dN7DwzTNWM5/lmmvBfmu50+QNU04 klfVxjCXza8u2nBWAMSMHjZ+VmhDSFcKNuPh5gNSgqOrLKsELoVbdtgbes/eWyDi 2lrTVgqZSDlmKimQGYX/PZOGnN+4fhkyc2zC2wX3lYmZuK2+r2ZEORe2zzt1oiK4 xly2zN7AexkZpfKlaI/oC6DjnP04BKOnPDp3M169uxM7jT81MVL3qi7ZXqaFusnj XCobkBy/ts1s0svs9uGyHDweUWOCY0WGPoN4aPgDtP5AbLKcxrXTEnT20ZpRuXdW OeBAdb/Pz/UbAzuVoPKG4Vft8no/cNkWGLnB4wQSEL2xRG8YcfDXwyd3xyCwG/rX QLkcSl6t2lSU4uBXoPykNu8U9PDB0c8ZBUDR4Rz981Tr63y2EOLGbxImYubEkaSs dwaokoUXLiQLg869uUBtCaUNqXLsfj5fMCG08VrJcrxHwrMWlPsdSB/caBVVIUHN hcIoHOgop4a5cvrASA6p9dtYupFM5xlvwS6j13omJfea1OGxQG5bV8tSFMoD5cF7 JCz+M5FbotD7sJO+5gbYPPg8+iblKSFlCO+ttMpluW5+KdDF27bF1uyy10vfxwZh I1A1CGPmpQ84+cGFqdm5 =F1On -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Clustered LVM with iptables issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Digimer, I initially assumed you were familiar with ss or netstat and simply forgot about them. Seems I was wrong. Check the output of this: `ss -tpn` and `ss -upn`. Those commands give you the current open TCP and UDP connections, as well as the program that opened the connection. Check listening sockets with `ss -tpnl` and `ss -upnl` - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV8goOAAoJEDg5KY9j7GZYJ5IP/1XlnJnOO2g90PpGG3nRJ5uT PYKEOL6RmpDkuNWpYFHe20uKI2GrGHqE8XbFH4kfanj3A3BQm5mJ5s4oSBFV6P72 G90w2iOt6cQ6tqGzT9KIfG38IVWGyctw6X6wX4g5IGEqxTLRjhXMScEiNQPUFhRS BTyCTVLRUD705ufzLayabpz631PnauH88dW/1x82vqnr5eN+v3DsBUQX7AtIqBm6 k7VXFl1aeII25eolKZZE3jYPPGFqqL8euWGm92cO9M2nY+UzYFolA8cbop/as4Em mdtZ8boiF1D6ni+RT7S2RLqi8l6wlQsHVBR1RxbU54TkSyL9gOSj6h+hPAdsFGKl XpOxK3f82rq2tu60balEtDcVIWpk4KK+APVM5Tzr3PLufCaKbe8hc3Z73YHz8y1L h1iL9tjc2fBr0g1jhJoZ5anAsjFWUVxx/gBbzFuhtcCKaAA2AksppwxF2Je97Uwk QKiM/rTs24CenNnm9sgFBwCawoGbkPrU8q8F4cCCX4OGmnFYUlYnDI5qZQ3lOUIJ iLOaK3/438GUimCyCbh4UjlmtSzprRY2tkqo3JsfP7VwmTzswtd+AiPjSuEBvW/F iL8f6aYtFz8iqOZiWxqSONUp4NSzo13d/ZlXlILP9+gk+d9SxtOegQAOxs5OsoNR DlQMMzw3nREfDV35X+MU =gjFh -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Clustered LVM with iptables issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Digimer, Pro tip: look at the 'multiport' module. You can substantially reduce the number of rules with it. Right now, I'm scratching my eyes out. You can use `ss` or `netstat` to find out where clmvd wants to phone to. That might be an additional lead. Or use tcpdump. But please, tidy up your rules. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV8gTcAAoJEDg5KY9j7GZYeXYP/R6bRPrSYXUnRPOyES9bZmxJ haxLVLW5YluFJS33YUYzWPaluzwQwcI9V4twfju7EeZJgh1Uo1kfA1fptduPaRK+ FuSi9TXPfVadLrbwksyyhgGp1UEFAqgcyd2TJlm+rQUbXTSxkS6kBJ0ypi/LHH8o YR7CC40EfdkRokDRqgt92AZ2Cj/l1jItt7Z4JEfc2t2fMo6axHRNdG3XBu52p66F +kQqqli8zfK8bRffmURVYiXW1qjzZlYfPIlbT4fqpdvvuC2lyXDdZvgajr/D3YOb 3EzGOmvEjB2G6IHFWKTUSpCJ7XOpR1+8iK1nb3jirTBa5sH8Rfbn/I0LQm0FfsrU EODHCWMD5nRD/f81dBy2biQ+HkggCu3x23lZUMa89sVUcwXMtnyC+NtnBN5JXtEH xD1hYemseKcPugEZJDDkjO/8NVG5V/sB/J4OWbKN1T7D3BQRyV9VU07wVFYToAyf EtSeV7rMYXioS8Pif5v/uXOUHtya59OGYiP4MLf8lcm9dUOmf9A8geVweZMvDU8b 4moek00gunDJVasISAgS1o6h0exKz7+lkLtgrMV+rIhRJkpJFa94x4KcjZE6zPnG 6Rmi9t+GzPpy07R209Fqz/C8TvhRN9qHhjt5XaEveD2Wj8MHtT4id4qa65p4Fi35 nvivpAeBLwYJlnI8vokJ =/Jd0 -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] 2 Nodes Pacemaker for Nginx can only failover 1 time
Hello Jacob, Look at the journal. It will tell you. Also, it's hard to debug without any information from the daemons. Regards, Noel Kuntze Am 9. August 2015 05:02:15 MESZ, schrieb jun huang : >Hello Everyone, > >I setup a cluster with two nodes with pacemaker 1.1.10 on CentOS 7. >Then I >downloaded aresource agent for nginx from github ><https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/nginx> > >I tested my setup like this: > > 1. Node 1 is started with the nginx and vip, everyting is ok > 2. Kill Node1 nginx, wait for a few seconds > 3. See the ngnix and vip are moved to node2, failover succeeded, and > Node1 doesn't have any resources active > 4. I kill nginx on node2, but nginx and vip don't come back to Node1 > >I set no-quorum-policy="ignore" and stonith-enabled="false". > >Why won't pacemaker let the resource come back to Node1? What did I >miss >here? > > >I guess the node1 is still in some failure status, how can I recovery >the >node? Does anyone can shed some light on my questions? Thank you in >advance. > >Thanks, > >Jacob > > > > >___ >Users mailing list: Users@clusterlabs.org >http://clusterlabs.org/mailman/listinfo/users > >Project Home: http://www.clusterlabs.org >Getting started: >http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >Bugs: http://bugs.clusterlabs.org -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] fence-virtd reach remote server serial/VM channel/TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Jan, I know that increasing the complexity reduces the availability of a service, so it is no surprise to me that it is frowned upon running services, which should be highgly available, on virtual machines. However, services are regularely run on VMs and HA is desired, even if the only thing that should be "protected" against is the downtime when the kernel needs to get upgraded or a daemon needs to be restarted. So I think fence-virt has a use case. My use case currently is to build a HA cluster of VMs, which currently host a simple mirror for software packages. They're stored on shared storage, which has a partition formatted with GFS2 on it. I use pcs(d), pacemaker, corosync and fence-virt over a serial device to fence hosts. Obviously, a single serial connection I currently only have one hypervisor, but could expand to more. I'm doing this, because I want to write a doc about clustering on Linux in the year 2015, so clustering on VMs is definitely a use case that I will describe. I know that multicast should actually work in common use cases, but I found that for some reason, the bridge device of the VMs don't forward traffic for the default multicast group of fence-virt to the other bridge ports, rendering it useless. I haven't dug deeper why that happens, but through Googling I found that it's a common problem that bridge devices on Linux don't forward some types of traffic. Obviously, if multicast works, one can just relay multicast networks over several other interfaces to relay requests. The man page of virt_fence.conf mentions "libvirt-qmf" as backend, instead of "libvirt", which should be able to route fencing requests to the correct host by using Apache QMF. I figure that's the correct backend for such a purpose. Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 05.08.2015 um 21:09 schrieb Jan Pokorný: > On 02/08/15 16:30 +0200, Noel Kuntze wrote: >> I would like to know if it is possible for >> fence-virtd to realy a request from a client, which it >> received via serial, VM channel or TCP connection >> from an agent to another daemon, if the VM that should >> be fenced does not run on the same host as the contacted daemon. > > First, it doesn't sound like very commendable or at least common setup > to have virtualized cluster nodes spread around multiple hosts. > When increasing the complexity of a deployment, new points of failure > can be introduced, defeating the purpose of HA. > > Could you please share details of your use case? > > > To your question, it might (hypothetically) be doable if you manage to > put the guests on the first host together with the other host into > the same multicast-friendly network or will rely multicast packets > between those "remote" sides by other means. > > Alternatively, you might implement such relying directly as > fence_virtd module (backend), possibly reusing some code from the > client side (fence_virt). > > > > ___ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVwsgQAAoJEDg5KY9j7GZY15kP/0iScwPftMkssy5K33Cj1Qa5 9jOwOAB35yNoecsfpG26b1jLN2V0XsNOQa1NKp9L6lx0TXiv/2D9meu9/aRckVG5 rPgzl4zuOeNrdIYzN+AHruDfIiqbtxwRQ83taUulP+rtYAspJt8KwcjQiyp4MkGp IyH4YphbN7jWKl/EwNqSsneEIjI6jZrD93DFVI9wmCsg1zKd8IcOAaAeB86q9C24 JQE4s8tvxOw6BkoIEZq8fBC4aFvhBBSKvoBUwvTUnlcTWwoxraHRbXz+R+F+Zr3Z Db6kOMs2q5Ogscpv2xlJaP5VCGgsCSMEesJT3hBR4AgSWbHgexlKKG1PGRTBUWz3 EuhC7TR66tfldTS8mbiZ6lqdjeXneRnEWIhZaCwHWOu8k4Q5ap5X8r1PYnzJIEXA XKfJquPuSiesyflMdxxMZeDCW/Fme8V9dF8cy6TzUrEjLAqPo7kyXtxJxzXJk5x3 qWcsF9BIhoExfX0jx6pYes4ArzxGw8umUB4Sp5J0smAI5V8+DUp2NHNNjRdfeHfd fwwchC8sruX51pQEiniOv2FfejwTKqv/Qqd+A+ps1/02j4S/jITcVWBX819RTswJ UA1bSS/dSFZc0DEZhUCxdgJYuAQ/1SPNePK2Okb9BgX24phoF5/f5NuDGTA9ZUN2 IgiMTn7O0gx0fhz+nS4l =OBVz -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] fence-virtd reach remote server serial/VM channel/TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Helli list, I would like to know if it is possible for fence-virtd to realy a request from a client, which it received via serial, VM channel or TCP connection from an agent to another daemon, if the VM that should be fenced does not run on the same host as the contacted daemon. - -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVvimQAAoJEDg5KY9j7GZY9XUP/A3ECXCdx0t84mIw4of9WFts NdWJPZNOLA9iY+1KWTzfLAP7S+teHBEfad2dfl+6B++Pcy17KbptmmP9rSK07THw pUIro6VHr7vjOjiPqaagGCmFqn0F6M0jvDX9XvJfn3Tj9HFHmXFqGfp9Z4+Lshi0 1UCQ1aF3Hr1XgdsZXegSHtp5ChyZR/QS/OJbAIwx6/bfGAgHZIK7RPF7iJfaRwAK BfFyC6FyHyy1ji63iDx3lTZPioSK9ffUxGYjD2MKtzHL1SaHGab/MKibx+vkOSDq kQ/wcq78J7edj5rlU3Z5idxDioN6/XZFtNG654zLRn5uKBmQhDcEE8OCjiuA/1fS HmoJf//uWch+XB0xmKRk3tWzu3E6DEDRuEwch8lI3sunRpEMgLfyof2nY8VJBhMt Cbs+F7FnX36gtXTF/jyGVShoDxDLpabAbnr1gNQjgVet+vrlpi5L1BLZdq4AiJBx NiPhuru5Atk8sXU59DCC/MzHppRN1yMQ1yQsK+wcaHCrhBmDv7G57hCQ5EV22Y0P S4CmyZGD9fjbHTvbq+b47VMuKl0RhRRNY+Ldqjhq50yWVVDjejKLviH7Gjm7k0rF a3Qo9DAjDjZAtlrUg32FdT78zDHA/7mpqXUqa4+xjXjx4o6T+aStJV8ttIXcfiFU 6B50w45u/gTtbT7OUNc2 =Cbdk -END PGP SIGNATURE- ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
