<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 2:56 PM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 10, 2017 at 2:27 PM, Martin Perina <span dir="ltr"><<a href="mailto:mperina@redhat.com" target="_blank">mperina@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hi Gianluca,<br><br></div><div style="font-family:arial,helvetica,sans-serif">so generally speaking when host is in Maintenance status, engine doesn't communicate with this host, so you can do pretty much anything about it.<br></div></div></blockquote><div><br></div><div>Thanks for the detailed answer, Martin.</div><div>It seemed to me that in the past I did a reboot at the host OS level while in maintenance and this generated a series of fencing/reboots of the host itself, so I wanted to be sure.</div><div>It is possible that at that time I also used "Confirm host has been rebooted" button, as initially I misunderstood its target.... and it was that action to generate fencing loops (2 or 3 I don't remember).</div><div>Then in Admin manual for 4.0 I saw that instead it is only to be used in case of unresponsive host, correct?</div><div> </div><div>"</div><div><div>If a host unpredictably goes into a non-responsive state, for example, due to a hardware failure;</div><div>it can significantly affect the performance of the environment. If you do not have a power</div><div>management device, or it is incorrectly configured, you can reboot the host manually.</div></div><div><br></div><div><div>Do not use the Confirm host has been rebooted option unless you have manually</div><div>rebooted the host. Using this option while the host is still running can lead to a virtual</div><div>machine image corruption.</div></div><div><br></div><div><div>Procedure 7.20. Manually fencing or isolating a non-responsive host<br></div><div>1. On the Hosts tab, select the host. The status must display as non-responsive.</div><div>2. Manually reboot the host. This could mean physically entering the lab and rebooting the</div><div>host.</div><div>3. On the Administration Portal, right-click the host entry and select the Confirm Host has</div><div>been rebooted button.</div><div>4. A message displays prompting you to ensure that the host has been shut down or</div><div>rebooted. Select the Approve Operation check box and click OK.</div></div><div>"</div><div><br></div><div>Initially I misread and kept focus only to the "Manually fencing" and "Manually reboot" but point 1. seems quite clear:</div><div>The status must display as non-responsive.<br></div><div>So no other use for "Confirm Host has been rebooted"</div><div>I will verify again the workflow<br></div></div></div></div></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">Right, by executing "Confirm Host has been rebooted" you take the responsibility and tell engine, that everything running on the host is really turned off. After that engine can change VM statuses do Down and restart HA VMs. But this option has to be used really carefully, otherwise you could cause data loss or even split brain. IMO this option should be used only if your hosts does not support Power Management (in this case you cannot have HA VMs) or you have some hardware failure which prevents power management to turn off the host.<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">About the upgrade flow (host 4.0 -> 4.1), here's proper way(s) how to achieve that:<br></div></div></blockquote><div><br></div><div>Yes, my question was in general, eg when I'm going to pass from 4.1.0.4 to 4.1.1</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">1. Put host to Maintenance<br>2. Add 4.1 repositories to the host<br></div><div style="font-family:arial,helvetica,sans-serif">3. Upgrade the host - you have 2 options here:<br></div><div style="font-family:arial,helvetica,sans-serif"> a. UI<br></div><div style="font-family:arial,helvetica,sans-serif"> - Go to Hosts tab in webadmin<br></div><div style="font-family:arial,helvetica,sans-serif"> - Select host and click on Reinstall inside Installation menu<br></div><div style="font-family:arial,helvetica,sans-serif"> b. Command line<br></div><div style="font-family:arial,helvetica,sans-serif"> - Connect to the host using SSH and upgrade using yum<br></div></div></blockquote><div><br></div><div>Sometimes at this point I could have a new kernel to boot, due to the update just completed, so the point 4. is not what I would like to do right now.</div></div></div></div></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">Yes, but this is OS upgrade, which should be done only manually via SSH and only when host is in Maintenance. </div> <div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">By "host upgrade" in oVirt terms we usually mean only upgrade of VDSM and dependent packages like libvirt or qemu-kvm ...<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"></div><div style="font-family:arial,helvetica,sans-serif">4. Activate the host<span style="font-family:arial,sans-serif"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">The main difference between UI and command line options is, that with UI option only necessary packages like VDSM and it's dependencies are upgraded.<br><br></div><div>Now regarding restart:<br></div><div> 1. If host is in Maintenance, restart using SSH and shutdown/reboot execution is no problem. But if host is Up, then executing shutdown/reboot using SSH will make host NonResponsive and fencing will be executed<br><br></div><div> 2. If you select Restart using SSH from Maintenance menu, it just connect using SSH and execute shutdown same way as it's done manually<br><br></div><div> 3. If you select Restart using Power Management from Maintenance menu, it will execute restart using PM device and further actions are hardware dependent. On some servers it will send shutdown signal to OS similarly as if you execute reboot and afterwards it turns off power of the server (so the result may be the same as using shutdown from command line). But on different hardware it can just turn off power of the server.<br></div><div><br></div><div>So for planned restart using SSH restart either from UI or from command line is preferred way.</div></div></blockquote><div><br></div><div><br></div><div>Ok, so a normal reboot is ok as point 4..</div><div>And then after reboot </div><div>5. Activate (and not "Confirm Host Has Rebooted"... ;-)</div></div></div></div></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">Right<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div>Regarding Power Mgmt ---> Restart</div><div>I thought that in general I should completely disable on the host the feature to initiate shutdown in case of power button pressed, like in RHCS or similar targeted environments:</div><div><a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/s2-acpi-disable-boot-CA.html" target="_blank">https://access.redhat.com/<wbr>documentation/en-US/Red_Hat_<wbr>Enterprise_Linux/6/html/<wbr>Cluster_Administration/s2-<wbr>acpi-disable-boot-CA.html</a><br></div><div><br></div><div>Is it not the case in oVirt? I think in case of fencing, it is necessary to have the host down as soon as possible</div><div>My initial question was the confirmation about Power Mgmt --> Restart : if it implied power Off / Power On by design or any other workflow....</div></div></div></div></blockquote><div><br><div style="font-family:arial,helvetica,sans-serif;display:inline" class="gmail_default">By design, restart using power management should use some device independent on host OS, so we can restart the host even thought you cannot connect to the OS.<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div>Thanks in advance,</div><div>Gianluca</div></div></div></div>
</blockquote></div><br></div></div>