1. Feature Overview: a) Name of feature: Support link-down detection of management LAN b) Feature Description: Currently, RHEV-M doesn't monitor management LAN and so it can't detect link-down in management LAN. With this feature, RHEV-M monitor management LAN in order to detect its link-down. 2. Feature Details: a) Architectures: 64-bit Intel EM64T/AMD64 b) Bugzilla Dependencies: None c) Drivers or hardware dependencies: None d) Upstream acceptance information: None e) External links: None f) Severity (H,M,L): High g) Feature Needed by: 2014 1Q
can you please elaborate - if the management network is down, rhev-m will move the host to non-responsive (and can send an email alert via the notification serviced)?
the power management has a "check status" option to validate the device and config are correct (the host itself may not have any access to it). it sounds like doing a power management status test every X minutes will cover this?
(In reply to Itamar Heim from comment #4) > the power management has a "check status" option to validate the device and > config are correct (the host itself may not have any access to it). How can we use that option? Host tab -> Select host -> Edit -> Power Management -> test? > it sounds like doing a power management status test every X minutes will > cover this? Yes, that's what we need.
(In reply to Satoru Moriya from comment #5) > (In reply to Itamar Heim from comment #4) > > the power management has a "check status" option to validate the device and > > config are correct (the host itself may not have any access to it). > > How can we use that option? > Host tab -> Select host -> Edit -> Power Management -> test? yes. you can also do this via scripting via the /api/hosts/<hostid>/fence with fence_type status option. > > > it sounds like doing a power management status test every X minutes will > > cover this? > > Yes, that's what we need. i suggest using scripting for now, but keeping this RFE open for considering adding hourly power management status check.
(In reply to Itamar Heim from comment #6) > (In reply to Satoru Moriya from comment #5) > > (In reply to Itamar Heim from comment #4) > > > the power management has a "check status" option to validate the device and > > > config are correct (the host itself may not have any access to it). > > > > How can we use that option? > > Host tab -> Select host -> Edit -> Power Management -> test? > > yes. you can also do this via scripting via the /api/hosts/<hostid>/fence > with fence_type status option. We can get power management status following 2 ways: 1. REST API # curl -X POST -H "Accept: application/xml" -H "Content-Type:application/xml" \ -u [USER:PASS] --cacert [CERT] \ -d "<action><fence_type>status</fence_type></action>" \ https://[RHEVM HOST]:443/api/hosts/[HOST id]/fence 2. rhevm-shell # rhevm-shell -c -l "https://[RHEVM HOST]/api" -u USER -A rhevm.cer # action host [HOST] fence --fence_type status But, unfortunately, we can't find any reference for #2, in particular, options for fence action (e.g. --fence_type) in "RHEV3.2 Command Line Shell Guide". https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html/Command_Line_Shell_Guide/index.html We guessed the option name, --fence_type, from XML which we use in #1(REST API). Do you have any documents which refer --fence_type option etc?
moving bug to guides component to review the documentation for missing part. thanks for the reoprt.
(In reply to Itamar Heim from comment #8) > moving bug to guides component to review the documentation for missing part. > thanks for the reoprt. Thanks. Fixing documentation is really helpful to us. On the other hand, originally, we would like to have the following feature which you mentioned in #4 and opened this bz. > it sounds like doing a power management status test every X minutes will > cover this? So, we'd like to keep this bz to RFE not document fix for considering adding hourly power management status check. How do we handle both fixing document and RFE request? Should we open bz for each request? (Should we open a new bz for fixing document?)
good point. changing title accordingly and moving back. I'll also clone for the docs issue.
*** Bug 845232 has been marked as a duplicate of this bug. ***
Hi Eli, What is the behaviour decided on the end according to comment 18? In other words what should be tested here and how?
(In reply to Tareq Alayan from comment #19) > Hi Eli, > > What is the behaviour decided on the end according to comment 18? > In other words what should be tested here and how? Please read the feature doc http://www.ovirt.org/Features/Design/DetailedPMHealthCheck
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html