Hi Josh,
Thanks for taking a look at this. I 'm answering your questions inline.
On 03/04/2015 10:01 PM, Josh Durgin wrote:
[...]
And then proceeded to create a qemu-kvm guest with rbd/server as its
backing store. The guest booted but as soon as it got to mount the root
fs, things got weird:
What does the qemu command line look like?
I am using libvirt, so I'll be copy-pasting from the log file:
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
/usr/libexec/qemu-kvm -name server -S -machine
rhel6.5.0,accel=kvm,usb=off -cpu
Penryn,+dca,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
-m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
ee13f9a0-b7eb-93fd-aa8c-18da9e23ba5c -nographic -no-user-config
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/server.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot order=nc,menu=on,strict=on -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -drive
file=rbd:libvirt-pool/server:id=libvirt:key=AQAeDqRTQEknIhAA5Gqfl/CkWIfh+nR01hEgzA==:auth_supported=cephx\;none,if=none,id=drive-scsi0-0-0-0
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
-netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:73:98:a9,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
[...]
scsi2 : Virtio SCSI HBA
scsi 2:0:0:0: Direct-Access QEMU QEMU HARDDISK 1.5. PQ: 0
ANSI: 5
sd 2:0:0:0: [sda] 20971520 512-byte logical blocks: (10.7 GB/10.0 GiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2
sd 2:0:0:0: [sda] Attached SCSI disk
dracut: Scanning devices sda2 for LVM logical volumes vg_main/lv_swap
vg_main/lv_root
dracut: inactive '/dev/vg_main/lv_swap' [1.00 GiB] inherit
dracut: inactive '/dev/vg_main/lv_root' [6.50 GiB] inherit
EXT4-fs (dm-1): INFO: recovery required on readonly filesystem
This suggests the disk is being exposed as read-only via QEMU,
perhaps via qemu's snapshot or other options.
You're right, the disk does seem R/O but also corrupt. The disk image
was cleanly unmounted before creating the snapshot and cloning it.
What is more, if I just flatten the image and start the guest again it
boots fine and there is no recovery needed on the fs.
There are also a some:
block I/O error in device 'drive-scsi0-0-0-0': Operation not permitted (1)
messages logged in /var/log/libvirt/qemu/server.log
You can use a clone in exactly the same way as any other rbd image.
If you're running QEMU manually, for example, something like:
qemu-kvm -drive file=rbd:rbd/server,format=raw,cache=writeback
is fine for using the clone. QEMU is supposed to be unaware of any
snapshots, parents, etc. at the rbd level.
In a sense, the parameters passed to QEMU from libvirt boil down to your
suggested command line. I think it should work as well, it is written
all over the place :)
I'm a still a newbie wrt ceph, maybe I am missing something flat-out
obvious.
Thanks for your time,
-K.
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
