[Bug 893450] Re: libvirt fails to start correctly because LVM is not ready

[Peter Petrakis]

In re-examining the evidence and chatting with Serge a few things come
to mind.

1) There's a disparity between the conclusion formed in comment #3 and the latest
udev logs. It could easily be true that the udev logging simply was held long enough
for that last LV to be activated. It appears to be true that if we wait long enough
(approx 10 mins) that all LVs will come online.

2) The crux is udev being starved of events or is it being stalled by
some other action?

3) Comment #9 compelled me to dig around concerning the backing store's to the
RAID 1 software set. The WD20EARS appear to use 4K sectors, which if true
would lend credence to *slowness* being the factor (udev is starved) which
determines why it takes almost 10 mins to discover all the LVs.

Follow up:
1) verify sector size of backing stores by installing sg3-utils and posting the result of
 # sg_readcap /dev/sda
and
 # cat /sys/block/sda/queue/physical_block_size

2) the basic dd test is fine, please re-run with a sweep of blocksizes, 512, 4k, 8k, 1024k
with "count=100" so it doesn't run forever

3) an additional io benchmark would be informative like iozone or iometer, whatever
is your preference.

Conclusion:
If this is an alignment issue then we've got a lot of work to do. You might be able
to resize/grow the MD array to change the stripe size to be a multiple of the sector
size. Though you would need to carry the exercise all the way through, including LVM
metadata offsets. It would be optimal if you had a duplicate set of drives to reproduce
this issue on a separate system. Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to udev in Ubuntu.
https://bugs.launchpad.net/bugs/893450

Title:
  libvirt fails to start correctly because LVM is not ready

Status in “libvirt” package in Ubuntu:
  New
Status in “udev” package in Ubuntu:
  New

Bug description:
  Some times, one of the KVM guest failed to start. I've 3 guest, two
  started OK and one failed (the two times the same has failed). After
  rebooting the host two times, the KVM guest started OK, but this is a
  server and found too risky this behavior. The host server is running
  "Ubuntu 11.04 Server 64bits" and libvirt 0.8.8-1ubuntu6.5

  The two times that failed, I've found this on syslog:

  error : virSecurityDACSetOwnership:125 : unable to set user and group to '105:115' on '/dev/vg_default/lv_robot-pv0': No such file or directory
  kernel: [  200.354543] type=1400 audit(1321932141.068:11): apparmor="DENIED" operation="open" parent=2539 profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/dm-7" pid=2638 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=105
  kernel: [  200.692255] type=1400 audit(1321932141.408:12): apparmor="STATUS" operation="profile_load" name="libvirt-7262201f-566b-d0b1-16ec-0b404ccd5336" pid=2639 comm="apparmor_parser"
  libvirtd: 00:22:21.424: 2539: error : virSecurityDACRestoreSecurityFileLabel:143 : cannot resolve symlink /dev/vg_default/lv_robot-pv0: No such file or directory
  libvirtd: 00:22:21.707: 2539: error : qemuAutostartDomain:275 : Failed to autostart VM 'robot': unable to set user and group to '105:115' on '/dev/vg_default/lv_robot-pv0': No such file or directory

  The LVM device is on a software raid. Maybe this is taking too long to
  come up?

  FYI, running "aa-status" (after the reboots) gives me:
  apparmor module is loaded.
  9 profiles are loaded.
  9 profiles are in enforce mode.
     /sbin/dhclient
     /usr/lib/NetworkManager/nm-dhcp-client.action
     /usr/lib/connman/scripts/dhclient-script
     /usr/lib/libvirt/virt-aa-helper
     /usr/sbin/libvirtd
     /usr/sbin/tcpdump
     libvirt-7262201f-566b-d0b1-16ec-0b404ccd5336
     libvirt-c032ea0a-8c62-7730-fb4d-e1bf60c15a31
     libvirt-f06ad419-f312-f002-444f-3e51f40d2291
  0 profiles are in complain mode.
  4 processes have profiles defined.
  4 processes are in enforce mode :
     /usr/sbin/libvirtd (2459) 
     libvirt-7262201f-566b-d0b1-16ec-0b404ccd5336 (2521) 
     libvirt-c032ea0a-8c62-7730-fb4d-e1bf60c15a31 (2551) 
     libvirt-f06ad419-f312-f002-444f-3e51f40d2291 (2582) 
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/893450/+subscriptions