Description of problem: if a remote tcp connection to libguestfs is desired, it is not possible to use guestfs in this way. the backend qemu+tcp does not work. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. call register_backend("qemu+tcp://10.0.0.4/system") where 10.0.0.4 is a valid machine running libvirtd --listen on tcpports 2. error will be returned 3. Actual results: 2014-10-19 13:40:52.042 1 DEBUG nova.virt.disk.api [req-13ce690f-b19b-4c6c-860e-1844dd65f74a c68d50e324d04a62b875f92325d2617e 4ddd4fd753b047eeb3ff67b2c7721662] Unable to mount image /var/lib/nova/instances/819aa819-a457-4e68-817f-b290e1cc2ebc/disk with error Error mounting /var/lib/nova/instances/819aa819-a457-4e68-817f-b290e1cc2ebc/disk with libguestfs (invalid backend: qemu+tcp://10.0.0.4/system). Cannot resize. is_image_partitionless /usr/lib/python2.7/site-packages/nova/virt/disk/api.py:211 Expected results: backend is accepted Additional info: It appears backends are hard-coded into the backend processor in the codebase. As a result, tcp and ssh backends don't appear to be implemented at this time.
Richard, This isn't super high priority but it would be nice for upstream Kolla work. What we want to do is separate libvirt into one container and compute into another container, and run them in the same pod (kubernetes terminology for a collection of containers with the same network/disk name space). If you can fix, we would appreciate it. Regards -steve
So I'm a bit confused .. where is the register_backend call? It's not in libguestfs ...
Anyhow, you can set the backend to "libvirt:<any libvirt URL>" (note the "libvirt:" prefix is required). However this won't make libguestfs work remotely. You have to ensure somehow that the disks of the guest are available at the same name (eg. they are NFS mounted, or use iSCSI, or bind-mounted at the same location). Or use libguestfs remote storage support[2]. Transparent remote support of disks[1] requires some quite deep changes to libvirt, which we never got around to doing because it's quite hard, would be really slow, and because libguestfs lets you access disks remotely in other ways now[2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=745282#c1 [2] http://libguestfs.org/guestfs.3.html#remote-storage
Even if you could make libguestfs point to a remote URI, this isn't going to make Nova as a whole work. Nova assumes that libvirtd + Nova are running on the same OS - you can't point to a remote libvirt hypervisor.
Dan, Thanks for letting me know Nova + libvirt must run in the same OS. I wasn't aware of that limitation.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22