yahoo-eng-team team mailing list archive

[Nikola Đipanov <ndipanov@xxxxxxxxxx>]

Public bug reported:

Libvirt driver will attempt to connect the volume on the hipervisor
twice for every volume provided to the instance when booting. If you
examine the libvirt driver's  spawn() method, both _get_guest_xml (by
means of get_guest_storage_config) and _create_domain_and_network will
call the _connect_volume method which works out the volume driver and
then dispatches the connect logic.

This is especially bad in the iscsi volume driver case, where we do 2
rootwraped calls in the best case, one of which is the target rescan,
that can in theory add and remove devices in the kernel.

I suspect that fixing this will make a number of races that have to do
with the volume not being present when expected on the hypervisor, at
least less likely to happen, in addition to making the boot process with
volumes more performant.

An example of a race condition that may be caused or made worse by this
is: https://bugs.launchpad.net/cinder/+bug/1357677

** Affects: nova
     Importance: High
         Status: Confirmed


** Tags: libvirt volumes

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1359617

Title:
  libvirt: driver calls volume connect twice for every volume on boot

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  Libvirt driver will attempt to connect the volume on the hipervisor
  twice for every volume provided to the instance when booting. If you
  examine the libvirt driver's  spawn() method, both _get_guest_xml (by
  means of get_guest_storage_config) and _create_domain_and_network will
  call the _connect_volume method which works out the volume driver and
  then dispatches the connect logic.

  This is especially bad in the iscsi volume driver case, where we do 2
  rootwraped calls in the best case, one of which is the target rescan,
  that can in theory add and remove devices in the kernel.

  I suspect that fixing this will make a number of races that have to do
  with the volume not being present when expected on the hypervisor, at
  least less likely to happen, in addition to making the boot process
  with volumes more performant.

  An example of a race condition that may be caused or made worse by
  this is: https://bugs.launchpad.net/cinder/+bug/1357677

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1359617/+subscriptions