Bug 1111520
Summary: | [RFE] change the behaviour of soft-fencing when "required" networks are missing on a single node cluster | |||
---|---|---|---|---|
Product: | [Retired] oVirt | Reporter: | Sven Kieske <s.kieske> | |
Component: | ovirt-engine-core | Assignee: | bugs <bugs> | |
Status: | CLOSED NOTABUG | QA Contact: | Pavel Stehlik <pstehlik> | |
Severity: | high | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 3.5 | CC: | acathrow, gklein, iheim, ofrenkel, oourfali, s.kieske, yeylon | |
Target Milestone: | --- | Keywords: | FutureFeature, Triaged | |
Target Release: | 3.5.0 | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Enhancement | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1112933 (view as bug list) | Environment: | ||
Last Closed: | 2014-06-25 05:12:12 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1112933 |
Description
Sven Kieske
2014-06-20 08:39:42 UTC
PS: I got my understanding how the fencing process works from: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Administration_Guide/Virtual_Machine_Networks_and_Optional_Networks.html If this should be wrong, please open a bug on the rhev docs (I can't do that as I have no running subscription, this limits btw your access to user reported bugs in official docs, as we can't assist in getting better docs without a subscription) addtionally the docs are somewhat unclear what it means that the vms get "fenced". do they get soft-fenced by acpi call to ovirt-guest-agent or do they get hard-fenced (powered off)? please attach engine && vdsm logs.. As far as I know the information in the documentation is wrong. There isn't supposed to be any "fencing" of any kind in such a use-case. If the host is responsive (management network is up and the host is responding), and another network isn't up, then the host will become non-operational. That should trigger a migration of all the VMs on this host. However, if there is no other "Up" host in the cluster then the migration will not happen, and the VMs will keep on running on the host. Can you attach logs? Sorry for letting you wait, I'll attach the logs today, just need to tar them together and need to make them anonymous. I'd like to provide some logs in private, as they contain sensitive information which may be important in debugging this problem and thus can't be deleted from the logs, is this possible? I submitted the logs in private to Omer Frenkel. If there is still missing something, just ping me via IRC, Mail or BZ. Thanks Sven! After looking at the logs, and verifying with Sven online in IRC, we see that first there was a kernel panic on the host, which caused it to reboot, and when the host came back to UP, the network was missing (and of course all the vms) so the host moved to non-operational. so the vms going to down was not related to the host moving to non-operational. maybe this bug need to be moved to documentation, because i find this sentence confusing - from the link supplied in comment 1 : " When a required network becomes non-operational, the virtual machines running on the network are fenced and migrated to another host. " saying fenced and migrated is a little of a contrast, should be changed to explain that all VMs on the host will migrate (and not only the vms that use the network) and also according to the cluster policy (migration can be none/HA/All) I've opened a documentation bug, and closing this one. |