Bug 1030820 - Launching instance ignores acceleration type settings
Launching instance ignores acceleration type settings
Product: RDO
Classification: Community
Component: openstack-nova (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: RHOS Maint
Ami Jeain
Depends On:
  Show dependency treegraph
Reported: 2013-11-15 03:50 EST by Karel Piwko
Modified: 2014-06-16 10:08 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
RHEL 6.4 64 bit Host machine Fedora 19 64 bit as Host for OpenStack Controller in VirtManager
Last Closed: 2014-05-22 11:42:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Horizon UI screenshot (30.01 KB, image/png)
2013-11-15 03:51 EST, Karel Piwko
no flags Details

  None (edit)
Description Karel Piwko 2013-11-15 03:50:22 EST
Description of problem:

I'm not able to spawn an instance in OpenStack Horizon UI, likely due to Nova ignororing acceleration settings and KVM nested virtualization is not supported by RHEL 6.4 kernel, hence VMX flag is not available no processor running Fedora 19 OpenStack controller.

Version-Release number of selected component (if applicable):

OpenStack installed according to https://wiki.brq.redhat.com/RHEVM-QE/OpenStackWorkshop

Nov 14 14:16:12 Installed: 1:python-novaclient-2.15.0-1.fc20.noarch
Nov 14 14:16:52 Installed: python-nova-2013.2-1.fc20.noarch
Nov 14 14:16:57 Installed: openstack-nova-common-2013.2-1.fc20.noarch
Nov 14 14:17:00 Installed: openstack-nova-api-2013.2-1.fc20.noarch
Nov 14 14:18:50 Installed: openstack-nova-console-2013.2-1.fc20.noarch
Nov 14 14:22:09 Installed: openstack-nova-compute-2013.2-1.fc20.noarch
Nov 14 14:22:51 Installed: openstack-nova-conductor-2013.2-1.fc20.noarch
Nov 14 14:23:10 Installed: openstack-nova-novncproxy-2013.2-1.fc20.noarch
Nov 14 14:23:14 Installed: openstack-nova-scheduler-2013.2-1.fc20.noarch
Nov 14 14:23:20 Installed: openstack-nova-cert-2013.2-1.fc20.noarch

How reproducible:


Steps to Reproduce:
1. Prepare OpenStack environment
2. Load cirrus image
3. Launch instance

Actual results:

Instance is stuck.

nova      3795 39.9  6.5 1409396 324116 ?      Rl   08:30   5:23 /usr/bin/qemu-system-x86_64 -machine accel=kvm -global virtio-blk-pci.scsi=off -nodefconfig -nodefaults -nographic -machine accel=kvm:tcg -m 500 -no-reboot -no-hpet -kernel /var/tmp/.guestfs-162/kernel.1827 -initrd /var/tmp/.guestfs-162/initrd.1827 -device virtio-scsi-pci,id=scsi -drive file=/var/lib/nova/instances/dc78c50d-7399-4b5f-9aa7-d1dedbbfd53b/disk,cache=none,format=qcow2,id=hd0,if=none -device scsi-hd,drive=hd0 -drive file=/var/tmp/.guestfs-162/root.1827,snapshot=on,id=appliance,if=none,cache=unsafe -device scsi-hd,drive=appliance -device virtio-serial -serial stdio -device sga -chardev socket,path=/tmp/libguestfsLxYA75/guestfsd.sock,id=channel0 -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 -append panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 TERM=linux

Expected results:

Instance will boot up.

Additional info:

* No errors is /var/log/nova/{conductor|compute}.log.
* Configuration of /etc/nova/nova.conf contains:
* Restarting host does not help, restarting services neither

* However, if the OpenStack Host is shutdown and started, instance that was in swawning mode can be started using Startup Instance button, resulting into:

qemu      3103 21.0  4.7 2040584 234776 ?      Sl   08:27   3:18 /usr/bin/qemu-system-x86_64 -name instance-00000005 -S -machine pc-i440fx-1.4,accel=tcg,usb=off -m 512 -smp 1,sockets=1,cores=1,threads=1 -uuid feeb9944-82b7-4e2f-9f15-f52738daa6dc -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=2013.2-1.fc20,serial=3050e828-75a7-749b-c966-7a321d5e4beb,uuid=feeb9944-82b7-4e2f-9f15-f52738daa6dc -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000005.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/feeb9944-82b7-4e2f-9f15-f52738daa6dc/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:6c:4f:43,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/feeb9944-82b7-4e2f-9f15-f52738daa6dc/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
Comment 1 Karel Piwko 2013-11-15 03:51:23 EST
Created attachment 824357 [details]
Horizon UI screenshot

Attachnig a screenshot of Horizon UI.
Comment 3 Lars Kellogg-Stedman 2014-02-10 15:58:42 EST

Can you confirm if you still this behavior with the current RDO Havana packages?  I am running RDO Havana on F19 without nested virtualization and I am able to successfully boot instances.

Note You need to log in before you can comment on or make changes to this bug.