Version bump of libvirt to 0.6.4 Reproducible: Always Steps to Reproduce:
Created attachment 193946 [details] libvirt 0.6.4 ebuild An ebuild that works in both configurations I need it to, based on 0.6.3-r3 from Portage.
Created attachment 193949 [details] updated kvm-img patch by Doug Goldstein The old kvm-img patch wouldn't apply against 0.6.4, so I shamelessly ripped this from Doug Goldstein's recent upstream submission.
Created attachment 193951 [details] libvirt 0.6.4 ebuild Oops, I forgot this fix: I have no idea why this keeps making it into ebuilds, but there is no reason to require any local virtualization driver. In fact, use of libvirtd, one of the most powerful uses of libvirt is almost completely broken by this requirement. In such a scenario you would have: 1. One or more machines running Xen, KVM, etc, with libvirtd 2. One or more libvirt 'client' machines, with no virtualization software installed. It might just be your workstation. In this case libvirt uses the 'remote' driver to connect to machines running libvirtd. The entire point of the remote driver is that local drivers are unnecessary.
I actually just added it to the tree. Give it a whirl and lemme know how it works. I pulled in another patch that appears to fix another issue in the storage backend but I could always be wrong.
libvirt SSH connections do not function correctly with the net-analyzer/netcat package required by this ebuild. The libvirt guys appear to be using the OpenBSD netcat which allows them to forward Unix Domain Sockets (the -U option). Portage's current netcat doesn't do that. The way I see it, either libvirt needs a big fat warning message that says "SSH connections to other libvirt daemons will not work as expected" or we need to get the netcat-openbsd ebuild into Portage and start depending on that package instead. Thoughts? Am I crazy and the only one experiencing this problem?
