yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: nova
       Status: Fix Committed => Fix Released

** Changed in: nova
    Milestone: None => juno-1

-- 
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/1305423

Title:
  nova libvirt re-write broken with mulitiple ephemeral disks

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  Seem to be experiencing a bug with libvirt.xml device formatting when --ephemeral flag is used after initial booth and then use of nova stop/start or nova reboot --hard.  We are using following libvirt options in nova.conf for storage:
  libvirt_images_type=lvm
  libvirt_images_volume_group=vglocal

  When normally using nova boot with a flavor that has ephemeral defined it create two LVM volumes appropriatly ex.
  instance-0000077e_disk
  instance-0000077e_disk.local

  The instance libvirt.xml contains disk devices entry as follows:
  <devices>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-0000077e_disk"/>
        <target bus="virtio" dev="vda"/>
      </disk>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-0000077e_disk.local"/>
        <target bus="virtio" dev="vdb"/>
      </disk>

  
  If we use "nova boot --flavor 757c75fa-0b6d-4d4f-a128-27813009bff4 --image caa978e0-acae-4205-a4a4-2cf159c166fd --nic net-id=44f2fb0b-0a7a-475c-8fff-54cd4b37958b --ephemeral size=1 --ephemeral size=1 localdisk-1" the LVM disks for ephemeral goes through enumeration logic whether there is one or more --ephemeral options
   instance-000007ed_disk                                   
   instance-000007ed_disk.eph0  
   instance-000007ed_disk.eph1

  The instance libvirt.xml after instance spawn has disk device entries like below and the instances happily boots.
   <devices>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-000007ed_disk"/>
        <target bus="virtio" dev="vda"/>
      </disk>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-000007ed_disk.eph0"/>
        <target bus="virtio" dev="vdb"/>
      </disk>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-000007ed_disk.eph1"/>
        <target bus="virtio" dev="vdc"/>
      </disk>

  If nova stop/start or nova reboot --hard is executed the instance is destroyed and libvirt.xml gets recreated.  At this stage whatever values we passed with --ephemeral are not respected and libvirt.xml revirts to configuration that would have been generated without the use of the --ephemeral option like below where we only have one extra disk and it is not using the enumerated naming.  
    <devices>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-000007ed_disk"/>
        <target bus="virtio" dev="vda"/>
      </disk>
      <disk type="block" device="disk">
        <driver name="qemu" type="raw" cache="none"/>
        <source dev="/dev/vgephemeral/instance-000007ed_disk.local"/>
        <target bus="virtio" dev="vdb"/>
      </disk>

  
  This causes instances booting to fail at this stage.  The nova block_device_mapping table has records for all 3 devices.

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