similar to: guestfish Remote Images IPv6 Support

Unfortunately I do need to use the address explicitly as opposed to hostnames because the source of the data fed here is Ceph's monmap which returns the addresses explicitly. I've tried all the common ways to escape the : in the v6 address to no avail.  I definitely agree that the problem looks to be it parsing the colons as if the port comes next and then everything after that is

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

This worked wonderfully!  What are the odds of getting this upstream in the near future?  I'd rather not build from source in production. # ./run guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_tmpdir "/root/libguestfs/tmp" libguestfs:

On Mon, Apr 01, 2019 at 08:45:48AM -0500, Jonathan Wright wrote: > Unfortunately I do need to use the address explicitly as opposed to > hostnames because the source of the data fed here is Ceph's monmap > which returns the addresses explicitly. > > I've tried all the common ways to escape the : in the v6 address to > no avail.  I definitely agree that the problem looks

On Fri, Mar 29, 2019 at 06:17:17PM -0500, Jonathan Wright wrote: > I have scoured the web and can't find anything on the topic: Is IPv6 > supported for remote image targets? It definitely should work, although I don't know if anyone has tried using the address explicitly (rather than a hostname which resolves to an AAAA record). > For example: > > guestfish --format=raw

On Mon, Apr 01, 2019 at 09:45:56AM -0500, Jonathan Wright wrote: > 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

Hello, Current version adding 'auth_supported=none' at the end of disk path and failing to do an authentication with specified cephx key: <source protocol='rbd' name='rbd/vmxxxxxxxxx:id=qemukvm:key=[cut]==:auth_supported=cephx'> <host name='10.0.0.13' port='6789'/> <host name='10.0.0.10' port='6789'/>

Hello, I'm having a problem when trying to use virt-sysprep against vms that have rbd disk images. When I run virt-sysprep I get the following error: >> root@kitt:~/libguestfs-1.22.4# virt-sysprep -d server-clone-test --firstboot firstboot.sh >> Examining the guest ... >> Fatal error: exception Guestfs.Error("rbd: image name must begin with a '/'") My

Hello, I'm having trouble connecting to rbd images. It seems like somewhere the name is getting chewed up. I wonder if this is related to my previous troubles [1] [2] with rbd images. I'm trying to add an rbd image, but when I launch the guestfs object I get an error: >> libguestfs: trace: launch = -1 (error) I'm adding a single RBD >> libguestfs: trace: add_drive

On Mon, Nov 25, 2013 at 09:58:50PM +0000, Richard W.M. Jones wrote: > On Mon, Nov 25, 2013 at 12:52:21PM -0700, Jon wrote: > > Hello, > > > > I'm having trouble connecting to rbd images. It seems like somewhere the > > name is getting chewed up. I wonder if this is related to my previous > > troubles [1] [2] with rbd images. > > > > I'm

Hello Richard, Haha, ok, here's a good one: I commented that if statement 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

Hello Richard, Thanks for the reply. Indeed this behaviour exists in 1.25.6. Grepping through the source [1], there are a number of files in "./po/*.po[t]?" that contain this message, but I think it's ./src/drives.c where the fail condition is actually detected / set. On line 300 there is an if statement that checks the first character is a slash: if (exportname[0] !=

Hello, I have virtual machines running with a ceph storage backend. When creating an external qcow2 snapshot with a libvirt version without support for the new object secret passing, the backing file info would list the ceph secret in plain,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

Miscellaneous fixes to: - Handling of Ceph drives now works end-to-end (RHBZ#1026688). - In particular, you can now use rbd:/// URIs in guestfish (and they work). - Parse Ceph & NBD network drives from libvirt XML correctly, so that existing domains with Ceph/NBD drives can be added (eg. using guestfish -d option). - Add more testing of the above.

Hi everybody, my background: I'm doing Xen since 10++ years, many years with DRBD for high availability, since some time I'm using preferable GlusterFS with FUSE as replicated storage, where I place the image-files for the vms. In my current project we started (successfully) with Xen/GlusterFS too, but because the provider, where we placed the servers, uses widely CEPH, we decided to

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.

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.

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

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

On Mon, Nov 25, 2013 at 12:52:21PM -0700, Jon wrote: > Hello, > > I'm having trouble connecting to rbd images. It seems like somewhere the > name is getting chewed up. I wonder if this is related to my previous > troubles [1] [2] with rbd images. > > I'm trying to add an rbd image, but when I launch the guestfs object I get > an error: > > >>