| 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.fischer@xxxxxxxxx |
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
