[libvirt-users] Is virsh supposed to work on Windows?

[Fernando Lozano]

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

[Eric Blake]

Post by Fernando Lozano
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.

Post by Fernando Lozano
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.

[Fernando Lozano]

Hi,

Post by Eric Blake

Post by Fernando Lozano
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. :-(

Post by Eric Blake

Post by Fernando Lozano
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. :-(

Post by Eric Blake
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

Post by Eric Blake
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

[Marc-André Lureau]

This post might be inappropriate. Click to display it.

[Fernando Lozano]

Hi,

Post by Marc-André Lureau

Post by Fernando Lozano

Post by Eric Blake

Post by Fernando Lozano
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.

Post by Marc-André Lureau
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. :-(

Post by Marc-André Lureau

Post by Fernando Lozano

Post by Eric Blake
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.

Post by Marc-André Lureau

Post by Fernando Lozano
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.

Post by Marc-André Lureau

Post by Fernando Lozano
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

[Fernando Lozano]

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

[i iordanov]

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

Post by Fernando Lozano
Hi,

Post by Fernando Lozano
I'm trying to use virsh and virt-viewer on Windows. I'm running the

Post by Fernando Lozano

Post by Fernando Lozano

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?

Post by Fernando Lozano
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

Post by Fernando Lozano

Post by Fernando Lozano

Post by Fernando Lozano
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.

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,

Post by Fernando Lozano

Post by Fernando Lozano
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,

Post by Fernando Lozano

Post by Fernando Lozano
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
http://lists.freedesktop.org/**mailman/listinfo/spice-devel<http://lists.freedesktop.org/mailman/listinfo/spice-devel>

[Christophe Fergeau]

Post by Fernando Lozano

Post by Eric Blake
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

[Christophe Fergeau]

Post by Christophe Fergeau

Post by Fernando Lozano

Post by Eric Blake
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

[Fernando Lozano]

Hi Christophe,

Post by Christophe Fergeau

Post by Christophe Fergeau
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

[Christophe Fergeau]

Post by Fernando Lozano

Post by Christophe Fergeau

Post by Christophe Fergeau
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.
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.

Post by Fernando Lozano
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

[Eric Blake]

[redirecting to libvir-list for a libvirt bug]

Post by Christophe Fergeau

Post by Fernando Lozano
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.

[Daniel P. Berrange]

Post by Eric Blake
[redirecting to libvir-list for a libvirt bug]

Post by Christophe Fergeau

Post by Fernando Lozano
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

[Eric Blake]

Post by Daniel P. Berrange

Post by Eric Blake
[redirecting to libvir-list for a libvirt bug]

Post by Christophe Fergeau

Post by Fernando Lozano
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.

[Fernando Lozano]

Hi Cristophe,

Post by Christophe Fergeau

Post by Fernando Lozano
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

[Christophe Fergeau]

Post by Fernando Lozano
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

[Fernando Lozano]

Hi,

Post by Christophe Fergeau

Post by Fernando Lozano
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

[Eric Blake]

Post by Fernando Lozano
Hi,

[I made several drafts before hitting send - I hope I am not stepping on
toes in trying to make my intended point]

Post by Fernando Lozano

Post by Christophe Fergeau

Post by Fernando Lozano
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]

[Marc-André Lureau]

----- Original Message -----

Post by Eric Blake

Post by Fernando Lozano
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.

Post by Fernando Lozano
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