search for: mon_host

I believe the bug lies in libguestfs. Taking out the commands being sent to QEMU and using qemu-img info I can recreate the error: # qemu-img info "rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none" qemu-img: Could not open 'rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none': invalid conf option :cefc:1]:6789:auth_supported: No such file or directory When escaping the : in the v6 address (jus...

This series improves ceph rbd support in libguestfs. It uses the servers list, adds support for a custom username, and starts to add support for custom secret.

...original drive content libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/root/libguestfs/tmp" libguestfs: trace: disk_create "/root/libguestfs/tmp/libguestfs9gclsg/overlay1.qcow2" "qcow2" -1 "backingfile:rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00\:\:cefc\:1]\:6789:auth_supported=none" "backingformat:raw" libguestfs: command: run: qemu-img libguestfs: command: run: \ create libguestfs: command: run: \ -f qcow2 libguestfs: command: run: \ -o backing_file=rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00\:\:cef...

...rue" >> "format:raw" "protocol:rbd" "server:tcp:[fd00::cefc:1]:6789" > This is probably where it goes wrong: > >> "/tmp/libguestfs3pGMi6/overlay1.qcow2" "qcow2" -1 "backingfile:rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none" >> "backingformat:raw" >> libguestfs: command: run: \ -o backing_file=rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none,backing_fmt=raw >> libguestfs: command: run: \ /tmp/libgues...

...atement out at line 300, applied your patch (I see you updated the github of this code, perhaps that's the best place to grab the code from), and when I run virt-sysprep, I get the following parameter for my disk drive: >> qemu-system-x86_64: -drive file=rbd:ibvirt-pool/server-clone-test:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789:auth_supported=none,cache=writeback,id=hd0,if=none: error opening pool ibvirt-pool Since "ibvirt-pool" doesn't exist. :) So this says to me that the function "create_drive_non_file" is consuming that first slash som...

...t; error: internal error: process exited while connecting to monitor: W: kvm binary is deprecated, please use qemu-system-x86_64 instead >> char device redirected to /dev/pts/5 (label charserial0) >> qemu-system-x86_64: -drive file=rbd:/libvirt-pool/server-clone-test:auth_supported=none:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789,if=none,id=drive-ide0-0-1: pool name too short >> qemu-system-x86_64: -drive file=rbd:/libvirt-pool/server-clone-test:auth_supported=none:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789,if=none,id=drive-ide0-0-1: cou...

...;> libguestfs: trace: add_drive "libvirt-pool/build_vm_test-os" "format:raw" "protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789 192.168.0.40:6789" But it seems like the name is getting chewed up in the call to kvm: >> -drive file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none >> disk image rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none: Invalid argument I am able to add non rbd images without a...

v1 -> v2: - Rebase on top of Pino's version work. Two patches went upstream, these are the two remaining patches. Note the generation number is still inside the qemu.stat file. We could put it in the filename, I have no particular preference. Rich.

...creating COW overlay to protect original drive content libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/tmp" libguestfs: trace: disk_create "/tmp/libguestfs3pGMi6/overlay1.qcow2" "qcow2" -1 "backingfile:rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none" "backingformat:raw" libguestfs: command: run: qemu-img libguestfs: command: run: \ create libguestfs: command: run: \ -f qcow2 libguestfs: command: run: \ -o backing_file=rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\...

..." > > "format:raw" "protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789 > > 192.168.0.40:6789" > > > > But it seems like the name is getting chewed up in the call to kvm: > > > > >> -drive > > file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none > > >> disk image > > rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none: > > Invalid argument > > &...

...port='6789'/> <host name='10.0.0.10' port='6789'/> <host name='10.0.0.17' port='6789'/> </source> results to: 0.10.1 -drive file=rbd:rbd/vmxxxxxxxxx-YSG:id=qemukvm:key=[cut]:auth_supported=cephx:auth_supported=none:mon_host=10.0.0.13\:6789\;10.0.0.10\:6789\;10.0.0.17\:6789,if=none,id=drive-virtio-disk0,format=raw,bps_rd=80000000,bps_wr=40000000,iops_rd=400,iops_wr=200 0.9.13 -drive file=rbd:rbd/vmxxxxxxxxx-YSG:id=qemukvm:key=[cut]:auth_supported=cephx:mon_host=10.0.0.13\:6789\;10.0.0.10\:6789\;10.0.0.17\:6789,if=none...

...e connecting to monitor: W: > > kvm binary is deprecated, please use qemu-system-x86_64 instead > > >> char device redirected to /dev/pts/5 (label charserial0) > > >> qemu-system-x86_64: -drive > > > file=rbd:/libvirt-pool/server-clone-test:auth_supported=none:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789,if=none,id=drive-ide0-0-1: > > pool name too short > > >> qemu-system-x86_64: -drive > > > file=rbd:/libvirt-pool/server-clone-test:auth_supported=none:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:...

QEMU upstream has broken snapshot=on ... again. These two patches stop using it entirely. Instead we run 'qemu-img create' to create overlay disks as required. Note that the libvirt and UML backends were already doing this: The libvirt backend because <transient/> has never worked, and the UML backend was running uml_mkcow because the UML-equivalent syntax of snapshot=on was

...in,e.g. # virsh snapshot-create-as vm-123 --no-metadata --disk-only --diskspec sda,file=/var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2 # qemu-img info /var/lib/libvirt/qemu/snapshot/vm-123-wrapper.qcow2 ... backing file: rbd:vms_pool0/disk-123:id=libvirt:key=SECRET:auth_supported=cephx\;none:mon_host=192.168.1.1\:6789\;192.168.1.11\:6789\;192.168.1.21\:6789 While this is problematic from a security perspective (and one of the reasons for the new method), it enabled starting the virtual machine again in case it died or got powered off. With the newer libvirt object secret passing the backing f...

Doing qemu feature detection in the direct backend takes ~100ms because we need to run `qemu -help' and `qemu -devices ?', and each of those interacts with glibc's very slow link loader. Fixing the link loader is really hard. Instead memoize the output of those two commands. This patch series first separates all the code dealing with qemu into a separate module (src/qemu.c) and

...applied your patch (I see you updated the github of this code, perhaps > that's the best place to grab the code from), and when I run virt-sysprep, > I get the following parameter for my disk drive: > > >> qemu-system-x86_64: -drive > file=rbd:ibvirt-pool/server-clone-test:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789:auth_supported=none,cache=writeback,id=hd0,if=none: > error opening pool ibvirt-pool > > Since "ibvirt-pool" doesn't exist. :) > > So this says to me that the function "create_drive_non_file" is consu...

..."libvirt-pool/build_vm_test-os" > "format:raw" "protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789 > 192.168.0.40:6789" > > But it seems like the name is getting chewed up in the call to kvm: > > >> -drive > file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none > >> disk image > rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none: > Invalid argument > > I am able to add...

...rror: process exited while connecting to monitor: W: > kvm binary is deprecated, please use qemu-system-x86_64 instead > >> char device redirected to /dev/pts/5 (label charserial0) > >> qemu-system-x86_64: -drive > file=rbd:/libvirt-pool/server-clone-test:auth_supported=none:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789,if=none,id=drive-ide0-0-1: > pool name too short > >> qemu-system-x86_64: -drive > file=rbd:/libvirt-pool/server-clone-test:auth_supported=none:mon_host=192.168.0.40\:6789\;192.168.0.35\:6789\;192.168.0.2\:6789,if=none,id=driv...

..." "protocol:rbd" "server:192.168.0.35:6789 192.168.0.2:6789 > > > 192.168.0.40:6789" > > > > > > But it seems like the name is getting chewed up in the call to kvm: > > > > > > >> -drive > > > > file=rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none,cache=writeback,format=raw,id=hd0,if=none > > > >> disk image > > > > rbd:libvirt:mon_host=192.168.0.35\:6789\;192.168.0.2\:6789\;192.168.0.40\:6789:auth_supported=none: > > > Invalid a...

..._type = identify_disk_image(file) File "/usr/lib64/xen/bin/pygrub", line 56, in identify_disk_image fd = os.open(file, os.O_RDONLY) OSError: [Errno 2] No such file or directory: 'rbd:devel-pool/testvm3.rbd:id=libvirt:key=AQBThwFbGFRYFxxxxxxxxxxxxxxx==:auth_supported=cephx\\;none:mon_host=10.20.30.1\\:6789\\;10.20.30.2\\:6789\\;10.20.30.3\\:6789' So the Xen-Python-script, that searches for the kernel/bootloader of the VM, does not find the imagefile. But if I grab the above output and use it with qemu, it does find the blockdevice: # qemu-img info "rbd:devel-pool/testvm3...