Bug 844130
Summary: | vm with direct lun fails to start | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] oVirt | Reporter: | Royce Lv <lvroyce> | ||||||
Component: | vdsm | Assignee: | Eduardo Warszawski <ewarszaw> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | unspecified | CC: | abaron, acathrow, amureini, bazulay, gickowic, iheim, jkt, mgoldboi | ||||||
Target Milestone: | --- | ||||||||
Target Release: | 3.3.4 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | storage | ||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 857889 (view as bug list) | Environment: | |||||||
Last Closed: | 2013-09-04 21:13:33 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 857889 | ||||||||
Attachments: |
|
Description
Royce Lv
2012-07-29 07:22:13 UTC
*** Bug 845179 has been marked as a duplicate of this bug. *** Please add libvirt, vdsm and engine complete logs. Tested in a loop, the VM always starts. Created attachment 603768 [details]
vdsm logs
Tested using a hosted with ISCSI session already set up.
The loop created a VM, tested to ensure it was up using virsh and then destroyed the VM.
500 iterations ran succesfully
Our test env is all in one,tgtd SCSI server also on the same machine.ISCSI session with no passwd. I recomand to reproduce in the following way : 1.create a new LUN, login 2.check /dev/mapper/xxx (xxx is the symlink of the LUN) pointed to a device with owner/group:root/disk 3.create a new vm using this direct LUN Gadi, I guess if you can make sure your disk owner/grp is root/disk before create vm, this problem can be reproduced. I checked your log and found you used this direct lun disk before your test.And if you already used the disk, it means the vdsm changed it's owner/group, so how many time you tried after, vm will be started successfully.This bug is triggered when first time use a fresh direct Lun disk. Edward, I checked the udev-182 source code, the write rules and reload rules are really ran in an async way,so there is indeed some race here. Created attachment 603837 [details]
engine_vdsm_libvirt logs
(In reply to comment #5) > Our test env is all in one,tgtd SCSI server also on the same machine.ISCSI > session with no passwd. > I recomand to reproduce in the following way : > 1.create a new LUN, login > 2.check /dev/mapper/xxx (xxx is the symlink of the LUN) pointed to a device > with owner/group:root/disk > 3.create a new vm using this direct LUN > > Gadi, > I guess if you can make sure your disk owner/grp is root/disk before create > vm, > this problem can be reproduced. > I checked your log and found you used this direct lun disk before your > test.And if you already used the disk, it means the vdsm changed it's > owner/group, so how many time you tried after, vm will be started > successfully.This bug is triggered when first time use a fresh direct Lun > disk. > > Edward, > I checked the udev-182 source code, the write rules and reload rules are > really ran in an async way,so there is indeed some race here. I actually changed the ownership back to root/disk after each run in the test loop after each machine is destroyed Gadi, Thanks for clarification. my udev is udev-182,shipped with fc17,according to its changeLog: move rules dirs to udev context; replace inotify with time-controlled stat() I guess if you are using old udev, the inotify will notify udev rules load to memory immediately,but the newest udev is doing like this: /* check for changed config, every 3 seconds at most */ if ((now_usec() - last_usec) > 3 * 1000 * 1000) { if (check_rules_timestamp(udev)) reload = true; if (udev_builtin_validate(udev)) reload = true; last_usec = now_usec(); } So it also depends on udev version. Upstream patch: http://gerrit.ovirt.org/#/c/6780/ in reload cmd in RHEL udev-173 is : # udevadm control --reload-rules but in fc17-udev-182 is: #udevadm control --reload Due to udev cmd change, choose to sleep waiting periodicalliy rules load instead of sychronized reload rules. |