On 16 April 2015 at 18:11, Anthony PERARD <anthony.per...@citrix.com> wrote: > Hi all, > > With libvirt_type=xen, the tempest test > tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern > fail. > > This is because it setup a volume with 'vda' as device_name and nova (well > libvirt) fail to bring up an instance. 'vda' (virtio) is not supported by > libvirt-xen. > > I tried to rename 'vda' to 'xvda' in the test, but then nova fail earlier. > When nova is setting up a block device list for the instance, it set a > value for boot_index. boot_index is set to 0 only if the device_name is > equal to root_device_name, which default to 'vda'. > The only way too change root_device_name is to add it to the metadata of > the image but I don't know if that a good idee. > > How could we resolve this? Skip the test if libvirt_type=xen? > > I have started to write a bug report for this: > https://bugs.launchpad.net/tempest/+bug/1443898
Hi, This on a bit of the API which feels too leaky around the virtualisation driver chosen :( We do have a horrific hack in place so it works with the XenAPI here: https://github.com/openstack/nova/blob/master/nova/compute/utils.py#L136 I guess its possible using that hack and tweaking the libvirt code could allow you to move forward with that. Longer term, we need a better way of dealing with these differences within the BDM code. Its possible there is something for this that I don't know about. Thanks, John __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev