Hi all
I'm playing with the boot from volume options in Havana and have run into
problems:
(Openstack Havana, Ceph Dumpling (0.67.4), rbd for glance, cinder and
experimental ephemeral disk support)
The following things do work:
- glance images are in rbd
- cinder volumes are in rbd
- creating a VM from an image works
- creating a VM from a snapshot works
However, the booting from volume options fail in various ways:
* Select "Boot from Image (create volume)"
fails booting, with the VM complaining that there was no bootable device "Boot
failed: not a bootable disk"
The libvirt.xml definition is as follows:
<disk type="network" device="disk">
<driver name="qemu" type="raw" cache="none"/>
<source protocol="rbd"
name="volumes/volume-fa635ee4-5ea5-429d-bfab-6e53aa687245">
<host name="xxxx:yyyy:0:6::11c" port="6789"/>
<host name="xxxx:yyyy:0:6::11d" port="6789"/>
<host name="xxxx:yyyy:0:6::11e" port="6789"/>
</source>
<auth username="volumes">
<secret type="ceph" uuid="e1915277-e3a5-4547-bc9e-4991c6864dc7"/>
</auth>
<target bus="virtio" dev="vda"/>
<serial>fa635ee4-5ea5-429d-bfab-6e53aa687245</serial>
</disk>
The qemu command line is this:
qemu-system-x86_64 -machine accel=kvm:tcg -name instance-00000187 -S -machine
pc-i440fx-1.5,accel=kvm,usb=off -cpu
SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
-m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
f28f9b90-9e75-45a7-ac34-c8dd2c6e3c5b -smbios type=1,manufacturer=OpenStack
Foundation,product=OpenStack
Nova,version=2013.2,serial=078965e4-1a79-0010-82d4-089e015a2b41,uuid=f28f9b90-9e75-45a7-ac34-c8dd2c6e3c5b
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000187.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew
-no-kvm-pit-reinjection -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=rbd:volumes/volume-fa635ee4-5ea5-429d-bfab-6e53aa687245:id=volumes:key=AQAsO2pSYEjXNBAAYB02+zSa2boqFcl+aZNwLw==:auth_supported=cephx\;none:mon_host=[xxxx\:yyyy\:0\:6\:\:11c]\:6789\;[xxxx\:yyyy\:0\:6\:\:11d]\:6789\;[xxxx\:yyyy\:0\:6\:\:11e]\:6789,if=none,id=drive-virtio-disk0,format=raw,serial=fa635ee4-5ea5-429d-bfab-6e53aa687245,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=30,id=hostnet0,vhost=on,vhostfd=31 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:93:a1:88,bus=pci.0,addr=0x3
-chardev
file,id=charserial0,path=/var/lib/nova/instances/f28f9b90-9e75-45a7-ac34-c8dd2c6e3c5b/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 0.0.0.0:4 -k en-us -vga cirrus -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
The volume is known to cinder:
cinder list --all-tenants | grep fa635ee4
| fa635ee4-5ea5-429d-bfab-6e53aa687245 | in-use |
| 10 | None | true |
f28f9b90-9e75-45a7-ac34-c8dd2c6e3c5b |
and rbd
root@hxs:~# rbd --pool volumes ls | grep fa635ee4
volume-fa635ee4-5ea5-429d-bfab-6e53aa687245
the file is a qcow2 file:
root@hxs:~# rbd map --pool volumes volume-fa635ee4-5ea5-429d-bfab-6e53aa687245
root@hxs:~# mount /dev/rbd2p1 /dev/rbd
mount: special device /dev/rbd2p1 does not exist
root@hxs:~# dd if=/dev/rbd2 of=foo count=100
root@hxs:~# file foo
foo: QEMU QCOW Image (v2), 2147483648 bytes
It is our understanding, that we need raw volumes to get the boot process
working. Why is the volume created as a qcow2 volume?
cheers
jc
--
SWITCH
Jens-Christian Fischer, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 15 71
jens-christian.fisc...@switch.ch
http://www.switch.ch
http://www.switch.ch/socialmedia
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
