<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html>
<head>
<meta name="Generator" content="Zarafa WebApp v7.1.10-44973">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>AW: [ovirt-users] Fake power management?</title>
</head>
<body>
<pre style="white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; white-space: pre-wrap; word-wrap: break-word;" wrap="">Hello Eli,<br><br>If I replace "/usr/bin/vdsm-tool service-restart vdsmd" with "echo b > /proc/sysrc-trigger", will the Engine consider the node to be fenced and restart the VMs that were running on it on another node? I don't see a mechanism to inform the engine that this was a "hard" fencing operation and that it's save to restart the guests.<br> <br>Regards,<br><br>mots<br> <br>-----Ursprüngliche Nachricht-----<br>> Von:Eli Mesika <<a href="mailto:emesika@redhat.com">emesika@redhat.com</a>><br>> Gesendet: Son 16 November 2014 03:00<br>> An: Patrick Lottenbach <<a href="mailto:pl@a-bot.ch">pl@a-bot.ch</a>><br>> CC: <a href="mailto:users@ovirt.org">users@ovirt.org</a><br>> Betreff: Re: [ovirt-users] Fake power management?<br>> <br>> <br>> <br>> ----- Original Message -----<br>> > From: "Sandro Bonazzola" <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>><br>> > To: "mots" <<a href="mailto:mots@nepu.moe">mots@nepu.moe</a>>, <a href="mailto:users@ovirt.org">users@ovirt.org</a><br>> > Sent: Friday, November 14, 2014 5:15:25 PM<br>> > Subject: Re: [ovirt-users] Fake power management?<br>> > <br>> > Il 14/11/2014 15:54, mots ha scritto:<br>> > > Hello,<br>> > > <br>> > > I'm building a small demonstration system for our sales team to take to a<br>> > > customer so that they can show them our solutions.<br>> > > Hardware: Two Intel NUC's, a 4 port switch and a laptop.<br>> > > Engine: Runs as a VM on one of the NUCs, which one it runs on is determined<br>> > > by pacemaker.<br>> > > Storage: Also managed by pacemaker, it's drbd backed and accessed with<br>> > > iscsi.<br>> > > oVirt version: 3.5<br>> > > OS: CentOS 6.6<br>> > <br>> > Just for curiosity, any reason for using pacemaker instead on oVirt Hosted<br>> > Engine solution?<br>> > <br>> > > <br>> > > The idea is to have our sales representative (or the potential customer<br>> > > himself) randomly pull the plug on one of the NUCs to show that the system<br>> > > stays operational when part of the hardware fails.<br>> > > My problem is that I don't have any way to implement power management, so<br>> > > the Engine can't fence nodes and won't restart guests that were running on<br>> > > the node which lost power. In pacemaker I can just configure fencing over<br>> > > SSH or even disable the requirement to do so completely. Is there<br>> > > something<br>> > > similar for oVirt, so that the Engine will consider a node which it can't<br>> > > connect to to be powered down?<br>> <br>> Well, we are thinking of adding such ability (Fake power management) mainly for testing purpose...<br>> Meanwhile, I think I have a work-around that may help you.<br>> <br>> When we have a connectivity issue with a node, we first try (after a grace period) to restart its VDSM via SSH <br>> this is always done before the hard-fencing (restart via the PM card) and can be done no matter if the host has PM configured or not.<br>> So basically when a connectivity issue is found, you can custom the SSH command that restarts VDSM to do whatever you want, even a script or a power-down command <br>> <br>> look at the result of <br>> <br>> > psql -U engine -c "select * from vdc_options where option_name ilike 'SshSoftFencingCommand'" engine<br>> <br>> option_id | option_name | option_value | version<br>> -----------+-----------------------+------------------------------------------+---------<br>> 558 | SshSoftFencingCommand | service vdsmd restart | 3.0<br>> 559 | SshSoftFencingCommand | service vdsmd restart | 3.1<br>> 560 | SshSoftFencingCommand | service vdsmd restart | 3.2<br>> 561 | SshSoftFencingCommand | /usr/bin/vdsm-tool service-restart vdsmd | 3.3<br>> 562 | SshSoftFencingCommand | /usr/bin/vdsm-tool service-restart vdsmd | 3.4<br>> 563 | SshSoftFencingCommand | /usr/bin/vdsm-tool service-restart vdsmd | 3.5<br>> <br>> <br>> Please note:<br>> <br>> 1) change only the value that match your cluster version<br>> 2) restart engine so change can take place <br>> 3) restore to default value again after you are done <br>> <br>> Does this may be useful for you ?<br>> <br>> <br>> <br>> > > <br>> > > Regards,<br>> > > <br>> > > mots<br>> > > <br>> > > <br>> > > _______________________________________________<br>> > > Users mailing list<br>> > > <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>> > > <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>> > > <br>> > <br>> > <br>> > --<br>> > Sandro Bonazzola<br>> > Better technology. Faster innovation. Powered by community collaboration.<br>> > See how it works at redhat.com<br>> > _______________________________________________<br>> > Users mailing list<br>> > <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>> > <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>> > <br>> </pre>
</body>
</html>