Good morning,
Does KVM/Qemu support booting from such a device?. I've seen it's able
to create images and so with qemu-img but... what about booting?. Have
read too it's possible but :
[root@kvm01 ~]# rbd -p KVM01 ls -l
NAME SIZE PARENT FMT PROT LOCK
DEBIAN01.img 6144M 2
Now :
[root@kvm01 ~]# qemu-system-x86_64 -m 1G -drive
format=raw,file=rbd:KVM01/DEBIAN01.img
(process:21587): GLib-WARNING **: gmem.c:483: custom memory allocation
vtable not supported
qemu-system-x86_64: -drive format=raw,file=rbd:KVM01/DEBIAN01.img: could
not open disk image rbd:KVM01/DEBIAN01.img: Unknown protocol
It seems it's supported, because I have created the image through
qemu-img (qemu-img create -f rbd rbd:KVM01/DEBIAN01.img 6G) but later
when trying to boot from
(although it would fail because no os is installed yet) it sais "Unkwown
protocol". My env is :
[root@kvm01 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@kvm01 ~]# uname -ar
Linux kvm01.ceph.sare.net 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25
20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@kvm01 ~]# rpm -qa | grep -i kvm
qemu-kvm-1.5.3-141.el7_4.6.x86_64
libvirt-daemon-kvm-3.2.0-14.el7_4.7.x86_64
qemu-kvm-common-1.5.3-141.el7_4.6.x86_64
[root@kvm01 ~]# rpm -qa | grep -i qemu
libvirt-daemon-driver-qemu-3.2.0-14.el7_4.7.x86_64
qemu-kvm-1.5.3-141.el7_4.6.x86_64
qemu-user-2.0.0-1.el7.6.x86_64
qemu-system-microblaze-2.0.0-1.el7.6.x86_64
qemu-system-x86-2.0.0-1.el7.6.x86_64
qemu-system-s390x-2.0.0-1.el7.6.x86_64
qemu-system-xtensa-2.0.0-1.el7.6.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
qemu-kvm-common-1.5.3-141.el7_4.6.x86_64
qemu-img-1.5.3-141.el7_4.6.x86_64
qemu-system-alpha-2.0.0-1.el7.6.x86_64
qemu-system-unicore32-2.0.0-1.el7.6.x86_64
qemu-system-or32-2.0.0-1.el7.6.x86_64
qemu-system-cris-2.0.0-1.el7.6.x86_64
qemu-system-arm-2.0.0-1.el7.6.x86_64
qemu-system-lm32-2.0.0-1.el7.6.x86_64
qemu-system-mips-2.0.0-1.el7.6.x86_64
qemu-2.0.0-1.el7.6.x86_64
qemu-common-2.0.0-1.el7.6.x86_64
qemu-system-moxie-2.0.0-1.el7.6.x86_64
qemu-system-sh4-2.0.0-1.el7.6.x86_64
qemu-system-m68k-2.0.0-1.el7.6.x86_64
[root@kvm01 ~]# rpm -qa | grep -i ceph
ceph-osd-10.2.10-0.el7.x86_64
ceph-radosgw-10.2.10-0.el7.x86_64
ceph-release-1-1.el7.noarch
libcephfs1-10.2.10-0.el7.x86_64
ceph-common-10.2.10-0.el7.x86_64
ceph-selinux-10.2.10-0.el7.x86_64
ceph-mds-10.2.10-0.el7.x86_64
ceph-10.2.10-0.el7.x86_64
python-cephfs-10.2.10-0.el7.x86_64
ceph-base-10.2.10-0.el7.x86_64
ceph-mon-10.2.10-0.el7.x86_64
[root@kvm01 ~]#
[root@kvm01 ~]#
[root@kvm01 ~]# ceph health
HEALTH_OK
[root@kvm01 ~]# ceph -s
cluster 97192242-10ea-4d94-8536-4e02c807009f
health HEALTH_OK
monmap e1: 1 mons at {mon1=192.168.14.67:6789/0}
election epoch 16, quorum 0 mon1
osdmap e88: 3 osds: 3 up, 3 in
flags sortbitwise,require_jewel_osds
pgmap v21554: 192 pgs, 2 pools, 435 bytes data, 5 objects
120 MB used, 584 GB / 584 GB avail
192 active+clean
My last question. Even if it finally end up working is this
configuration stable and production ready?. By the way have not been
able to find nothing in log files....
>From KVM/Qemu perspective it's perhaps now better or more stable, to
boot and use rbd disks through krbd?.
Best regards,
