Re: [libvirt-users] [virt-tools-list] Is virsh supposed to work on Windows?
On 09/06/2013 10:03 AM, Daniel P. Berrange wrote:
On Fri, Sep 06, 2013 at 09:59:23AM -0600, Eric Blake wrote:
> [redirecting to libvir-list for a libvirt bug]
>
> On 09/06/2013 09:50 AM, Christophe Fergeau wrote:
>
>>>
>>> virsh.exe complains about missing libvirt-lcx-0.dll and doesn't starts.
>>
>> You should be able to grab it from
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=460929 even though I
>> don't think it's really useful to build that at all on mingw.
>>
>
> Indeed - libvirt-lxc-0.dll makes NO sense at all, because lxc is a
> Linux-only concept. I'll try and figure out why the mingw spec is
> attempting to compile a dll that should not be needed.
But the libraries are RPC clients, so in general they can be
run anywhere. ie disabling LXC or QEMU driver in libvirtd
does not imply that libvirt-lxc.dll and libvirt-qemu.dll should
be disabled.
Now it happens that libvirt-lxc.dll doesn't have any useful APIs
you can use on Windows yet, but that doesn't mean we shouldn't
compile it
Ah, I was thinking it had to do with running local LXC, but you are
correct that it exists to provide the client hooks into driver-specific
API that isn't deemed useful enough for the normal libvirt dll. So I
stand corrected, it does need to be built for mingw (even if none of the
hooks are useful yet). On the other hand, maybe virsh should be using
dynamic loading rather than having a hard-coded link dependency, so that
it still continues to work even when libvirt-lxc-0.dll is not present
(similarly for libvirt-qemu-0.dll) - it would just mean that commands
like 'virsh qemu-monitor-command' gracefully fail if the helper
libraries are not present, which isn't a bad restriction if you want to
use only fully-supported API.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)