[libvirt-users] Is virsh supposed to work on Windows?
Hi there, Sorry for the cross-post, but I seeked help on this issue before on those lists, but nobody answered. :-( 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? I know the kvm host setup (a CentOS 6.3 machine) is fine, because I can connect using virsh from other CentOS and RHEL machines. I'm using TLS to secure connenctions to libvirtd, without client certs. I had a litthe trouble finding where to put certificate files on the windows machine, but using Sysinternals ProcessMonitor I found they have to be on the obvious path: C:\usr\x86_64-w64-mingw32\sys-root\mingw\etc\pki{CA,libvirt} 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 ProcessMonitor "strace" doesn't help me find what went wrong. I'm sure I'm using the same *.pem files that works for Linux clients. It looks like virsh is opening and reading those files ok. ProccessMonitor shows a TCP connect and a TCP Disconnect events to the correct IP and port, both resulting SUCCESS. Any ideas? What can I do to debug virsh on Windows and find why it isn't connecting to libvirt on CentOS? I tried -d and -l on Windows and Linux but can't find where the debug logs are saved. If you want, I can send ProcessMonitor captured events. For Red Hat folks out there: I need this working so I can get approval to buy subscriptions, The idea is production hosts will be RHEL. :-) If not, my boss may end up buying XenServer ;-) []s, Fernando Lozano
On 09/04/2013 12:53 PM, Fernando Lozano wrote:
Hi there,
Sorry for the cross-post, but I seeked help on this issue before on those lists, but nobody answered. :-(
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.
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. 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? 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
----- Original Message -----
On 09/04/2013 12:53 PM, Fernando Lozano wrote:
Hi there,
Sorry for the cross-post, but I seeked help on this issue before on those lists, but nobody answered. :-(
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.
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.
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?
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.
It used to work for the basics, long time go. Then only kept the build going To check the version, you can msiextract the msi, and lookup Program Files\VirtViewer\deps.txt: mingw32-libvirt-0.10.2-3.fc19.noarch mingw32-libvirt-static-0.10.2-3.fc19.noarch cheers
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? :-) 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. :-(
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. :-(
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
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. :-) 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. :-( []s, Fernando Lozano
----- 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!)
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. 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).
If I were compiling and running on Linux, I'd give it a try despite my outdated C coding skills. But the current process of cross-compiling on Linux then running on Windows is not an easy one. Heck, if you readhatters and fedoraers who are used to do it doesn't do frequently, and have frequent dependency problems, what hope do I have to being able to do this -- even if I get approval from my boss? ;-) The ultimate goal is running virt-manager from Windows (but I found no port yet to test). It would be enough for the short-term being able to run at least virsh and virt-viewer so Windows syasdmins doesn't complain so much and doesn't tell my boss we should buy XenServer. (not kidding) It looks like the paths are not the issue with the code -- they were not easy to find, but this is a documenation probem. :-) I already send feedback to the lists about the correct paths for windows users. Sysinternals ProcessMonitor is a freeware windows tool that provides strace-like features, and from it I can tell reading the certificate files is not the problem anymore. It also shows no network errors and no other windows systemcalls issues.
If it's just accessing remote display, you could stick to remote-viewer? Yes you need to know the port though. If it were just for me I'd live with that. But other TI people here are complaining about "not user friendly" running remote-viewer directly and do not want to use Xming. So I need to provide an "easier" way to remote guest console access from windows, and also a way to run some kvm administration. As I said, they are already lobbying to move from KVM to something else. :-(
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.
As expected, deps.txt agrees with virsh -V: mingw32-libvirt-0.10.2-3.fc19.noarch mingw32-libvirt-static-0.10.2-3.fc19.noarch Same contents for both x64 and x86 virt-viewer 0.5.7 msi's from spice-space.org.
Do you know who built the Windows port? I know someone is doing that, because the binaries are updated 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. As a Linux user myself, I would't care less about the windows port ;-) But as an IT consultant, I see most potentical RHEL+KVM or RHEV users (and KVM + CentOS, Fedora, Debian, etc users) have windows workstations and no knowledge, worse yet, no interest in using X remote displays. Not to mention there are times you need the guest console, X remote won't be enough.
Besides it's very very inefficient accessing a guest console from virt-manager using Xming or other X server for Windows, with or without ssh. You are on an end-to-end 1Gbps LAN but feels like an ADSL connection or worse. :-( I'd argue to the Red Hat managers that windows ports of virt-manager and etc needs a higher priority if they want to grab market share from vmware, hyper-v or xenserver.
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!) The few docs I saw about porting Linux software for windows (like gimp) makes it look very hard, involving a significand investment in time just to get started and a deep knowledge about both platforms. Would you be able to provide a HOW-TO for virsh and maybe virt-viewer? I'm not telling I'd be able to spare the time, but I'd give it a try before calling defeat.
[]s, Fernando Lozano
Hey Fernando, 1) As a possible workaround, can't you put a Linux server with virt-manager installed somewhere, and then have the Windows sysadmins use it through X11 forwarding (with Xming, or Cygwin installed on the Windows machines)? 2) Also, if virt-manager can run under Cygwin, you can use it directly on the Windows machines that way (I don't know if it does). Cheers, iordan On Thu, Sep 5, 2013 at 3:01 PM, Fernando Lozano <fernando@lozano.eti.br>wrote:
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<http://spice-space.org/download.html>, that is, virt-viewer-x64-0.5.7.msi on a Windows 7 64-bits computer.
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).
If I were compiling and running on Linux, I'd give it a try despite my outdated C coding skills. But the current process of cross-compiling on Linux then running on Windows is not an easy one. Heck, if you readhatters and fedoraers who are used to do it doesn't do frequently, and have frequent dependency problems, what hope do I have to being able to do this -- even if I get approval from my boss? ;-)
The ultimate goal is running virt-manager from Windows (but I found no port yet to test). It would be enough for the short-term being able to run at least virsh and virt-viewer so Windows syasdmins doesn't complain so much and doesn't tell my boss we should buy XenServer. (not kidding)
It looks like the paths are not the issue with the code -- they were not easy to find, but this is a documenation probem. :-) I already send feedback to the lists about the correct paths for windows users.
Sysinternals ProcessMonitor is a freeware windows tool that provides strace-like features, and from it I can tell reading the certificate files is not the problem anymore. It also shows no network errors and no other windows systemcalls issues.
If it's just accessing remote display, you could stick to remote-viewer?
Yes you need to know the port though.
If it were just for me I'd live with that. But other TI people here are complaining about "not user friendly" running remote-viewer directly and do not want to use Xming. So I need to provide an "easier" way to remote guest console access from windows, and also a way to run some kvm administration. As I said, they are already lobbying to move from KVM to something else. :-(
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.
As expected, deps.txt agrees with virsh -V:
mingw32-libvirt-0.10.2-3.fc19.**noarch mingw32-libvirt-static-0.10.2-**3.fc19.noarch
Same contents for both x64 and x86 virt-viewer 0.5.7 msi's from spice-space.org.
Do you know who built the Windows port? I know someone is doing that,
because the binaries are updated 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.
As a Linux user myself, I would't care less about the windows port ;-) But as an IT consultant, I see most potentical RHEL+KVM or RHEV users (and KVM + CentOS, Fedora, Debian, etc users) have windows workstations and no knowledge, worse yet, no interest in using X remote displays. Not to mention there are times you need the guest console, X remote won't be enough.
Besides it's very very inefficient accessing a guest console from virt-manager using Xming or other X server for Windows, with or without ssh. You are on an end-to-end 1Gbps LAN but feels like an ADSL connection or worse. :-(
I'd argue to the Red Hat managers that windows ports of virt-manager and etc needs a higher priority if they want to grab market share from vmware, hyper-v or xenserver.
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!)
The few docs I saw about porting Linux software for windows (like gimp) makes it look very hard, involving a significand investment in time just to get started and a deep knowledge about both platforms. Would you be able to provide a HOW-TO for virsh and maybe virt-viewer? I'm not telling I'd be able to spare the time, but I'd give it a try before calling defeat.
[]s, Fernando Lozano
______________________________**_________________ Spice-devel mailing list Spice-devel@lists.freedesktop.**org <Spice-devel@lists.freedesktop.org> http://lists.freedesktop.org/**mailman/listinfo/spice-devel<http://lists.freedesktop.org/mailman/listinfo/spice-devel>
-- The conscious mind has only one thread of execution.
Hi,
1) As a possible workaround, can't you put a Linux server with virt-manager installed somewhere, and then have the Windows sysadmins use it through X11 forwarding (with Xming, or Cygwin installed on the Windows machines)? As I already told, I did this and my fellow sysadmins didn't liked. :-(
2) Also, if virt-manager can run under Cygwin, you can use it directly on the Windows machines that way (I don't know if it does). I found no cygwin-based binaries for virsh, virt-viewer or remote-viewer. So far only the mingw-based remote-viewer from spice-space.org works, but it's too little for my fellow sysadmins. I'm trying virsh and virt-viewer form the same package.
[]s, Fernando Lozano
On Wed, Sep 04, 2013 at 04:41:40PM -0300, Fernando Lozano wrote:
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
I've pushed test builds of mingw-virt-viewer packaging libvirt 1.1.2 if you want to give them a try to see if they work better (disclaimer: I haven't tested these installers at all). Christophe
On Thu, Sep 05, 2013 at 06:50:43PM +0200, Christophe Fergeau wrote:
On Wed, Sep 04, 2013 at 04:41:40PM -0300, Fernando Lozano wrote:
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
I've pushed test builds of mingw-virt-viewer packaging libvirt 1.1.2 if you want to give them a try to see if they work better (disclaimer: I haven't tested these installers at all).
Pushed to http://teuf.fedorapeople.org/virt-viewer-msi/ ;) Christophe
Hi Christophe,
I've pushed test builds of mingw-virt-viewer packaging libvirt 1.1.2 if you want to give them a try to see if they work better (disclaimer: I haven't tested these installers at all). Pushed to http://teuf.fedorapeople.org/virt-viewer-msi/ ;)
Thanks for providing those test binaries so quickly. The x64 package is missing DLLs. remote-viewer works fine, but: virsh.exe complains about missing libvirt-lcx-0.dll and doesn't starts. virt-viewer.exe complains about missing libssp-0.dll and doesn't starts -- this also happens with the "current" binaries from spice.org The x86 package remote-viwer also works fine, and has the same problem for virsh.exe. But virt-viewer.exe doesn't show any error. It simply locks up up until I terminate it using [Ctrl+C]. I provided complete command line args, the same ones that works from a Linux machine. Sysinternals ProcessMonitor shows virt-viewer.exe read the certificate files, connected to libvirtd on the host and received some data (many TCP Receive, TCP Send and TCP TCPCopy events with SUCCESS). The latest lines are a ThreadCreate and a ThreadExit event, botu SUCCESS. Nothing I could see to explain why it's locked. []s, Fernando Lozano
On Thu, Sep 05, 2013 at 03:30:12PM -0300, Fernando Lozano wrote:
I've pushed test builds of mingw-virt-viewer packaging libvirt 1.1.2 if you want to give them a try to see if they work better (disclaimer: I haven't tested these installers at all). Pushed to http://teuf.fedorapeople.org/virt-viewer-msi/ ;)
Thanks for providing those test binaries so quickly.
The x64 package is missing DLLs. remote-viewer works fine, but:
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.
virt-viewer.exe complains about missing libssp-0.dll and doesn't starts -- this also happens with the "current" binaries from spice.org
Not that surprising as the goal of this installer is to provide remote-viewer.exe, not virt-viewer.exe or virsh.exe. I'd tend to say we should not include them in the installer as they are not working anyway ;) libssp can be found from the gcc package on http://koji.fedoraproject.org/koji/buildinfo?buildID=444834 Christophe
[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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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 Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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
Hi Cristophe,
virt-viewer.exe complains about missing libssp-0.dll and doesn't starts -- this also happens with the "current" binaries from spice.org Not that surprising as the goal of this installer is to provide remote-viewer.exe, not virt-viewer.exe or virsh.exe. I'd tend to say we should not include them in the installer as they are not working anyway
I agree with this, and the msi installer should be named remote-viewer-X.YY.msi to reflect that. On the other side, there should be an official place for people like me, who are interested in testing virsh and virt-viewer (and who knows, some day virt-manager) on Windows, to get test binaries. There should be some effort on continuing the porting, not stopping on remote-viewer. []s, Fernando Lozano
On Fri, Sep 06, 2013 at 04:00:25PM -0300, Fernando Lozano wrote:
On the other side, there should be an official place for people like me, who are interested in testing virsh and virt-viewer (and who knows, some day virt-manager) on Windows, to get test binaries. There should be some effort on continuing the porting, not stopping on remote-viewer.
I fully agree with that, and that effort is best done by people interested in getting such a port ;) It's actually not very hard to get Windows builds cross compiled on linux (at least from Fedora), I can help you get started with that if you want, but I unfortunately can't/don't want to spend a lot of time on testing and debugging virsh Windows binaries :( Christophe
Hi,
On the other side, there should be an official place for people like me, who are interested in testing virsh and virt-viewer (and who knows, some day virt-manager) on Windows, to get test binaries. There should be some effort on continuing the porting, not stopping on remote-viewer. I fully agree with that, and that effort is best done by people interested in getting such a port ;) It's actually not very hard to get Windows builds cross compiled on linux (at least from Fedora), I can help you get started with that if you want, but I unfortunately can't/don't want to spend a lot of time on testing and debugging virsh Windows binaries :( Thanks for the offer, I'll take it, although without high expectations. It's a share there's so little interest from Red Hat.
[]s, Fernando Lozano
On 09/06/2013 04:22 PM, Fernando Lozano wrote:
Hi,
[I made several drafts before hitting send - I hope I am not stepping on toes in trying to make my intended point]
On the other side, there should be an official place for people like me, who are interested in testing virsh and virt-viewer (and who knows, some day virt-manager) on Windows, to get test binaries. There should be some effort on continuing the porting, not stopping on remote-viewer. I fully agree with that, and that effort is best done by people interested in getting such a port ;) It's actually not very hard to get Windows builds cross compiled on linux (at least from Fedora), I can help you get started with that if you want, but I unfortunately can't/don't want to spend a lot of time on testing and debugging virsh Windows binaries :( Thanks for the offer, I'll take it, although without high expectations. It's a share there's so little interest from Red Hat.
While this list (these lists, since this is cross-posted) has several contributors with Red Hat addresses, most of us here are engineers. and NOT financial decision-makers. Furthermore, libvirt is NOT exclusive to Red Hat - our goal is to be a community project with contributions from anyone interested (true, Red Hat employees make up a large percentage of interested contributors, but we try hard not to make it a Red Hat monopoly). To really determine if Red Hat is interested in your situation, you'd be better off talking with a Red Hat sales representative. The engineers here (including myself) have been taught (and rightly so, I might add) that trying to make definitive statements on public lists about what Red Hat will or won't support will almost always get us in hot water, and that both potential and existing clients can exercise much more leverage by going through the correct channels. Red Hat may be entirely interested in supporting your use case as a condition of gaining your business; and if you go through the proper channels, it may indeed result in a higher frequency of windows-related patches on these lists in reaction to what you are able to work out with your sales rep. There's also the possibility that you could consider contracting with someone other than Red Hat to get the functionality you want in virsh on windows. But as _this_ mailing list is not a sales channel, your comments about Red Hat's interest or dis-interest in your situation feel a bit off-base, and aren't adding to the technical conversation. As with most open source projects, something will get done as fast (or as slow) as it takes to find someone willing to scratch their own itch (including scratching their itch by hiring someone else to do the coding), all without needing to resort to off-topic comments about who or why someone else should do the work. [On a personal note, even if I were NOT sending mail from a redhat.com address, I would _still_ hope that you are able to work something out with a Red Hat sales rep, or with any other open source support vendor - everyone wins when more people are able to use an open source solution] -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (6)
-
Christophe Fergeau -
Daniel P. Berrange -
Eric Blake -
Fernando Lozano -
i iordanov -
Marc-André Lureau