Bug 819283
| Summary: | ovirt-engine-backend [RACE]: we can destroy a domain while its being activated | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Dafna Ron <dron> | ||||||
| Component: | ovirt-engine | Assignee: | mkublin <mkublin> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | vvyazmin <vvyazmin> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 3.1.0 | CC: | acathrow, amureini, bazulay, dyasny, hateya, iheim, lpeer, Rhev-m-bugs, yeylon, ykaul, yzaslavs | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | 3.1.0 | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | storage | ||||||||
| Fixed In Version: | si10 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-07-19 11:16:22 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
suggested patch : http://gerrit.ovirt.org/5179 pushed Created attachment 597546 [details]
logs vdsm.log $ engine.log
This bug reproduced on RHEVM 3.1 - SI9.1 RHEV-M: rhevm-3.1.0-5.el6ev.noarch VDSM: vdsm-4.9.6-17.0.el6.x86_64 LIBVIRT: libvirt-0.9.10-21.el6.x86_64 QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.295.el6.x86_64 [root@cougar08 ~]# vdsClient -s 0 getStorageDomainsList fb9e0f33-022d-4cc7-ab9a-0e6c8394c921 5cac9011-9ea4-4e53-a23e-2344aebad734 Domain: fb9e0f33-022d-4cc7-ab9a-0e6c8394c921 (name = SD-02-iSCSI) - was destroyed. [root@cougar08 ~]# vdsClient -s 0 getStorageDomainInfo fb9e0f33-022d-4cc7-ab9a-0e6c8394c921 uuid = fb9e0f33-022d-4cc7-ab9a-0e6c8394c921 vguuid = YrGidz-60g9-mkFK-FLr1-WJ2d-cFRo-p2fxWx lver = -1 state = OK version = 2 role = Regular pool = ['c63ea75d-2c36-4301-9cfb-657ac5a393ac'] spm_id = -1 type = ISCSI class = Data master_ver = 0 name = SD-02-iSCSI [root@cougar08 ~]# vdsClient -s 0 getStorageDomainInfo 5cac9011-9ea4-4e53-a23e-2344aebad734 uuid = 5cac9011-9ea4-4e53-a23e-2344aebad734 vguuid = zc1IP4-sE6M-s6Sg-VJRG-KaBE-0Cce-4OM9Og lver = 2 state = OK version = 2 role = Master pool = ['c63ea75d-2c36-4301-9cfb-657ac5a393ac'] spm_id = 1 type = ISCSI class = Data master_ver = 1 name = Storage-Domain-01-iSCSI This bug reproduced on RHEVM 3.1 - SI10 The system will not allow to ForceRemove same domain twice, but when I did Activate and move domain to status locked, I am releasing a memory lock, by defenition it is not important for ForceRemove status of domain and it will be removed. If ForceRemove was started before Activate, Activate will fail, but the case which is described at bug is not a bug. The problem is when I destroy the domain, the record not deleted from DB. When you run following command, before “destroy” action and after: vdsClient -s 0 getStorageDomainsList you get same results. |
Created attachment 582415 [details] logs Description of problem: activating a domain and starting a destroy action on the domain will cause the domain to be removed from DB but to be connected to the pool in vds. 1) except for vdsm and backend not being synced (which can cause some issues along the way) since the domains are listed in master domain metadata we will not be able to remove the master domain without destroy of DC. 2) locking mechanism should apply on this case since domain is suppose to be in locked state. Version-Release number of selected component (if applicable): si3 How reproducible: 100 Steps to Reproduce: 1. activate SD -> move to storage tab -> destroy the domain 2. 3. Actual results: domain is removed from DB and is activated and connected in vds. Expected results: 1) domain should be locked so action should be prevented by locking mechanism since its suppose to be in image locked. 2) we should also add validation with CanDoAction Additional info: [root@orange-vdsd ~]# vdsClient -s 0 getStorageDomainsList 7887bf00-181d-4861-8da4-26138c2ac94f 8d37aadd-9234-4c06-96e5-f551fca7cc3d 99b356f1-46f4-40bf-8e1b-b86ed4be9914 cc22fd05-fc11-42b5-90dd-19ecfffc6109 1c4b81c0-bc2b-4b57-9341-5179ee848abd these two domains were destroyed: [root@orange-vdsd ~]# vdsClient -s 0 getStorageDomainInfo 7887bf00-181d-4861-8da4-26138c2ac94f uuid = 7887bf00-181d-4861-8da4-26138c2ac94f vguuid = v0z3T0-qk8P-sBYO-3meb-WMnk-RGTe-q2RO61 lver = -1 state = OK version = 2 role = Regular pool = ['ce13371e-d637-4901-810d-73e2fdd90496'] spm_id = -1 type = ISCSI class = Data master_ver = 0 name = small2 [root@orange-vdsd ~]# vdsClient -s 0 getStorageDomainInfo 8d37aadd-9234-4c06-96e5-f551fca7cc3d uuid = 8d37aadd-9234-4c06-96e5-f551fca7cc3d vguuid = XuAqMC-pMEt-DTqO-eBa2-x7Y7-cZck-APG44u lver = -1 state = OK version = 2 role = Regular pool = ['ce13371e-d637-4901-810d-73e2fdd90496'] spm_id = -1 type = ISCSI class = Data master_ver = 0 name = small3