2:53 p.m.
----- Original Message -----
Hi,
>> I'm trying to use virsh and virt-viewer on Windows. I'm running the
>> latest binaries from http://spice-space.org/download.html, that is,
>> virt-viewer-x64-0.5.7.msi on a Windows 7 64-bits computer.
>>
>> So far I got remote-viewer.exe to work, after some pain. But have no
>> sucess using virt-viewer.exe and virsh.exe. Are they supposed to work,
>> or am I loosing my time?
> It will only work if someone interested enough submits patches.
This means it isn't supposed to work, or this means you don't know about
anyone trying to use those binaries besides me? :-)
The libvirt part hasn't been widely used on windows. Developers just keep it
compiling, afaik.
I am willing to help all I can to test, but I'm not a Gnome
developer. I
have not coded a single line in C for more than 10 yeas. :-(
You are lucky! :) libvirt is not a gnome technology. If you have some developper
experience, it might not be so hard to fix some of the issues (like the paths).
>> Even then virsh can't connect:
>>
>> virsh # connect qemu://kvmhost/system
>> error: Failed to connect to the hypervisor
>> error: Unable to set close-on-exec flag: Success
> Here, I wonder if we can't improve the situation;
> src/util/virutil.c:virSetInherit() does nothing, and its wrapper
> virSetCloseExec() should therefore always return 0, which makes it very
> suspicious - the message in src/rpc/virnetsocket.c about close-on-exec
> not working should never be reached.
If you (or someone else) sends me testing or debuging binaries, I'll be
glad to test them. I'll even setup another virtualization host if some
thinks a newer CentOS, RHEL or Fedora could help. But I won't be able to
code myself.
I hope someone at Red Hat gives attention to this, because most admins
of a RHEL / RHEV host runs Windows desktops. My home computer runs only
Fedora, but at work (most customers, anyway) I have to use Windows. :-(
If it's just accessing remote display, you could stick to remote-viewer? Yes you need
to know the port though.
> What version of virsh is included in that msi? Maybe it's
just a case
> of a stale build, for something that has been fixed upstream?
C:>virsh -V
Virsh command line tool of libvirt 0.10.2
See my previous reply. You can check the $prefix\deps.txt file for the build versions.
> But I personally have not tried to build or debug on mingw, to know if
> this is the only issue, or if you are staring at a number of other
> portability issues to resolve first.
Do you know who built the Windows port? I know someone is doing that,
because the binaries are updates every few months. :-)
Daniel & me? It's useful, since you found bugs. I could eventually fix them, but
libvirt on windows is probably not a priority... I would start by filling bugs.
I can see the last fedora build is 1.1.1, perhaps you can grab the rpm dlls and copy them
over your installation (but I am afraid that won't be that simple, if ABI changed or
other external requirements)
Again, I'm willing to help any way I can, but I can be only a
tester,
and a documentation writer. I won't be able to help as a developer. :-(
I would say hacking on libvirt windows is easy, as long as you have a windows (to run)
& a fedora (to build). Some issues could even be debugged with wine (yes!)