virt-viewer windows port

[anuj rampal]

Hi all,

I have build virt-viewer-0.2.0 for windows.

now when I tried to run that "virt-viewer.exe" for the 1st time.

it gave me this error:

(virt-viewer.exe:8464): Pango-WARNING **:
`Z:\usr\i686-pc-mingw32\sys-root\mingw
\lib\pango\1.6.0\modules\pango-basic-win32.dll': The specified module could
not
be found.

To solve this I had to rename one of my Disk to Z and the copied the
pango-basic-win32.dll at the specified path.

now it didnt give me any error.

But what happens now is:

1. virt-viewer.exe -c qemu+tcp://192.168.1.106/session 1 ; where
192.168.1.106 is the ip address of my machine where qemu is running and 1 is
the id of the VM.

2. A blank screen opens up with "virt-viewer.exe" written on its top and
then that program does not responds.

Could someone please help me out with this.

Thanks in advance

Regards
Anuj

[Richard W.M. Jones]

On Wed, Sep 23, 2009 at 07:08:53PM +0530, anuj rampal wrote:
> But what happens now is:
> virt-viewer.exe -c qemu+tcp://192.168.1.106/session 1 ; where
>
> 192.168.1.106 is the ip address of my machine where qemu is running and 1 is
> the id of the VM.
> A blank screen opens up with "virt-viewer.exe" written on its top and
>
> then that program does not responds.

How did you compile it?  Did you cross-compile it from Fedora or build
it using some other means?  How did you build libvirt / where did you
get libvirt from?

Try also running virt-viewer in verbose mode (with -v option).

Rich.

[anuj rampal]

yes i cross compiled it from FC11 using mingw.
i have also build libvirt-0.6.2 on the same machine using mingw and it works
fine..... i can call all the function of libvirt from my Vista machine.

but virt-viewer is not working...

also this only happens when i try to connect using tcp.
with ssh and tls it just says could not connect....??

On Wed, Sep 23, 2009 at 8:27 PM, Richard W.M. Jones wrote:
> On Wed, Sep 23, 2009 at 07:08:53PM +0530, anuj rampal wrote:
> > But what happens now is:
> > virt-viewer.exe -c qemu+tcp://192.168.1.106/session 1 ; where
> >
> > 192.168.1.106 is the ip address of my machine where qemu is running and 1
>
> is
> > the id of the VM.
> > A blank screen opens up with "virt-viewer.exe" written on its top and
> >
> > then that program does not responds.
>
> How did you compile it?  Did you cross-compile it from Fedora or build
> it using some other means?  How did you build libvirt / where did you
> get libvirt from?
>
> Try also running virt-viewer in verbose mode (with -v option).
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://et.redhat.com/~rjones/virt-top

[Richard W.M. Jones]

On Thu, Sep 24, 2009 at 10:20:32AM +0530, anuj rampal wrote:
> yes i cross compiled it from FC11 using mingw.
> i have also build libvirt-0.6.2 on the same machine using mingw and it works
> fine..... i can call all the function of libvirt from my Vista machine.
>
> but virt-viewer is not working...
>
> also this only happens when i try to connect using tcp.
> with ssh and tls it just says could not connect....??

You say above that libvirt "works", but I want you to try it in a
controlled environment.  First off, try some simple virsh commands:

virsh list
  virsh -c ... list

(with various connection strings).

Second, set the LIBVIRT_DEBUG environment variable to 1 (I have no
idea how you do that in Windows).  Then repeat the above commands.

Thirdly, try (with LIBVIRT_DEBUG=1):

virt-viewer -v -c ... host

Rich.

[anuj rampal]

Hi,

You say above that libvirt "works",

Yes, libvirt works.

By this I mean that I have sucessfully build the libvirt-0.7.0 for windows
using mingw.
So now i have libvirt-0.dll and virsh.exe.
Using this dll I can connect to the libvirtd server and call functions
successfully.

but I want you to try it in a
controlled environment.  First off, try some simple virsh commands:

virsh list
 virsh -c ... list

(with various connection strings).

Even virsh.exe also works fine when connect to TCP connection. and i can
call the functions without any issues.

But with TLS there was some certificate issue but after resolving this
issue, im still not able to connect to the libvirt
this is what it says:
> virsh.exe -c qemu://FC11-KVM/session

error: unable to connect to libvirtd at 'FC11-KVM': errno=22
error: failed to connect to the hypervisor

this is what it says...???? (this is from my vista machine)

from a different linux machine this works fine... (same uri = virsh -c
qemu://FC11-KVM/session)

Other connect strings are not supported on windows (unix, ssh, ext)
> virsh.exe -c qemu+ssh://FC11-KVM/session

error: invalid argument in transport methods unix, ssh and ext are not
supported
 under Windows
error: failed to connect to the hypervisor

this is what it says.

Second, set the LIBVIRT_DEBUG environment variable to 1 (I have no
idea how you do that in Windows).  Then repeat the above commands.

And i dont have to change any configuration on windows because i only have
dll and exe thats all....

every this has to be changed on the libvirt server(linux machine where
libvirtd is running).

virt-viewer -v -c ... host

i tried using different connection string on my vista machine

virt-viewer -c qemu+tcp://FC11-KVM/session gets connected. but hangs and
nothing happens.

virt-viewer -v -c qemu://FC11-KVM/session (i.e. tls)
gives error:
unable to connect to libvirt qemu://FC11-KVM/session

Regards
Anuj

On Thu, Sep 24, 2009 at 1:48 PM, Richard W.M. Jones wrote:
> On Thu, Sep 24, 2009 at 10:20:32AM +0530, anuj rampal wrote:
> > yes i cross compiled it from FC11 using mingw.
> > i have also build libvirt-0.6.2 on the same machine using mingw and it
>
> works
> > fine..... i can call all the function of libvirt from my Vista machine.
> >
> > but virt-viewer is not working...
> >
> > also this only happens when i try to connect using tcp.
> > with ssh and tls it just says could not connect....??
>
> You say above that libvirt "works", but I want you to try it in a
> controlled environment.  First off, try some simple virsh commands:
>
> virsh list
>  virsh -c ... list
>
> (with various connection strings).
>
> Second, set the LIBVIRT_DEBUG environment variable to 1 (I have no
> idea how you do that in Windows).  Then repeat the above commands.
>
> Thirdly, try (with LIBVIRT_DEBUG=1):
>
> virt-viewer -v -c ... host
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://et.redhat.com/~rjones/virt-top

[anuj rampal]

Hi,

Yes 1 more thing that i wanted to add:

when i tried these commands on a linux machine and tried to connect to
libvirtd running on a different remote machine:

virt-viewer -c qemu+tcp://FC11-KVM/session 1

and

virt-viewer -c qemu://FC11-KVM/session 1

nothing happens and it doesnot give any error also.

but works fine when i tried

virt-viewer -c qemu+ssh://FC11-KVM/session 1

the console opens up and i can see view the guest machine.

Regards
Anuj

On Thu, Sep 24, 2009 at 6:41 PM, anuj rampal  wrote:
> Hi,
>
> You say above that libvirt "works",
>
> Yes, libvirt works.
>
> By this I mean that I have sucessfully build the libvirt-0.7.0 for windows
> using mingw.
> So now i have libvirt-0.dll and virsh.exe.
> Using this dll I can connect to the libvirtd server and call functions
> successfully.
>
> but I want you to try it in a
> controlled environment.  First off, try some simple virsh commands:
>
> virsh list
>  virsh -c ... list
>
> (with various connection strings).
>
> Even virsh.exe also works fine when connect to TCP connection. and i can
> call the functions without any issues.
>
> But with TLS there was some certificate issue but after resolving this
> issue, im still not able to connect to the libvirt
> this is what it says:
> > virsh.exe -c qemu://FC11-KVM/session
>
> error: unable to connect to libvirtd at 'FC11-KVM': errno=22
> error: failed to connect to the hypervisor
>
> this is what it says...???? (this is from my vista machine)
>
> from a different linux machine this works fine... (same uri = virsh -c
> qemu://FC11-KVM/session)
>
> Other connect strings are not supported on windows (unix, ssh, ext)
> > virsh.exe -c qemu+ssh://FC11-KVM/session
>
> error: invalid argument in transport methods unix, ssh and ext are not
> supported
>  under Windows
> error: failed to connect to the hypervisor
>
> this is what it says.
>
> Second, set the LIBVIRT_DEBUG environment variable to 1 (I have no
> idea how you do that in Windows).  Then repeat the above commands.
>
> And i dont have to change any configuration on windows because i only have
> dll and exe thats all....
>
> every this has to be changed on the libvirt server(linux machine where
> libvirtd is running).
>
> virt-viewer -v -c ... host
>
> i tried using different connection string on my vista machine
>
> virt-viewer -c qemu+tcp://FC11-KVM/session gets connected. but hangs and
> nothing happens.
>
> virt-viewer -v -c qemu://FC11-KVM/session (i.e. tls)
> gives error:
> unable to connect to libvirt qemu://FC11-KVM/session
>
> Regards
> Anuj
>
> On Thu, Sep 24, 2009 at 1:48 PM, Richard W.M. Jones wrote:
> > On Thu, Sep 24, 2009 at 10:20:32AM +0530, anuj rampal wrote:
> > > yes i cross compiled it from FC11 using mingw.
> > > i have also build libvirt-0.6.2 on the same machine using mingw and it
> >
> > works
> > > fine..... i can call all the function of libvirt from my Vista machine.
> > >
> > > but virt-viewer is not working...
> > >
> > > also this only happens when i try to connect using tcp.
> > > with ssh and tls it just says could not connect....??
> >
> > You say above that libvirt "works", but I want you to try it in a
> > controlled environment.  First off, try some simple virsh commands:
> >
> > virsh list
> >  virsh -c ... list
> >
> > (with various connection strings).
> >
> > Second, set the LIBVIRT_DEBUG environment variable to 1 (I have no
> > idea how you do that in Windows).  Then repeat the above commands.
> >
> > Thirdly, try (with LIBVIRT_DEBUG=1):
> >
> > virt-viewer -v -c ... host
> >
> > Rich.
> >
> > --
> > Richard Jones, Emerging Technologies, Red Hat
> > http://et.redhat.com/~rjones
> > virt-top is 'top' for virtual machines.  Tiny program with many
> > powerful monitoring features, net stats, disk stats, logging, etc.
> > http://et.redhat.com/~rjones/virt-top

[Richard W.M. Jones]

On Thu, Sep 24, 2009 at 06:41:03PM +0530, anuj rampal wrote:
> But with TLS there was some certificate issue but after resolving this
> issue, im still not able to connect to the libvirt
> this is what it says:
>
> virsh.exe -c qemu://FC11-KVM/session
> error: unable to connect to libvirtd at 'FC11-KVM': errno=22
> error: failed to connect to the hypervisor
>
> this is what it says...???? (this is from my vista machine)

Apparently "errno 22" is EINVAL.

That doesn't help much.  I really need you to set the LIBVIRT_DEBUG
environment variable to 1 on order to show the full messages, and then
continue with the tests as outlined in the previous email.

http://support.microsoft.com/kb/310519

Rich.

[anuj rampal]

Hi,

1st i tried connecting to libvirt from a remote linux machine

This is the URI:
LIBVIRT_DEBUG=1 virt-viewer -c qemu://FC11-KVM/session 2

This is the result that i got:

11:28:15.602: debug : virInitialize:279 : register drivers
11:28:15.603: debug : virRegisterDriver:776 : registering Test as driver 0
11:28:15.603: debug : virRegisterNetworkDriver:614 : registering Test as
network driver 0
11:28:15.603: debug : virRegisterInterfaceDriver:645 : registering Test as
interface driver 0
11:28:15.603: debug : virRegisterStorageDriver:676 : registering Test as
storage driver 0
11:28:15.603: debug : virRegisterDeviceMonitor:707 : registering Test as
device driver 0
11:28:15.603: debug : virRegisterSecretDriver:738 : registering Test as
secret driver 0
11:28:15.603: debug : virRegisterDriver:776 : registering OPENVZ as driver 1
11:28:15.603: debug : vboxRegister:101 : VBoxCGlueInit failed, using dummy
driver
11:28:15.604: debug : virRegisterDriver:776 : registering VBOX as driver 2
11:28:15.604: debug : virRegisterNetworkDriver:614 : registering VBOX as
network driver 1
11:28:15.604: debug : virRegisterStorageDriver:676 : registering VBOX as
storage driver 1
11:28:15.604: debug : virRegisterDriver:776 : registering ESX as driver 3
11:28:15.604: debug : virRegisterDriver:776 : registering remote as driver 4
11:28:15.604: debug : virRegisterNetworkDriver:614 : registering remote as
network driver 2
11:28:15.604: debug : virRegisterInterfaceDriver:645 : registering remote as
interface driver 1
11:28:15.604: debug : virRegisterStorageDriver:676 : registering remote as
storage driver 2
11:28:15.604: debug : virRegisterDeviceMonitor:707 : registering remote as
device driver 1
11:28:15.604: debug : virRegisterSecretDriver:738 : registering remote as
secret driver 1
11:28:15.604: debug : virConnectOpenAuth:1273 :
name=qemu://FC11-KVM/session, auth=0x9bfe40, flags=1
11:28:15.604: debug : do_open:1042 : name "qemu://FC11-KVM/session" to URI
components:
  scheme qemu
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
11:28:15.604: debug : do_open:1052 : trying driver 0 (Test) ...
11:28:15.604: debug : do_open:1058 : driver 0 Test returned DECLINED
11:28:15.604: debug : do_open:1052 : trying driver 1 (OPENVZ) ...
11:28:15.604: debug : do_open:1058 : driver 1 OPENVZ returned DECLINED
11:28:15.604: debug : do_open:1052 : trying driver 2 (VBOX) ...
11:28:15.604: debug : do_open:1058 : driver 2 VBOX returned DECLINED
11:28:15.604: debug : do_open:1052 : trying driver 3 (ESX) ...
11:28:15.604: debug : do_open:1058 : driver 3 ESX returned DECLINED
11:28:15.604: debug : do_open:1052 : trying driver 4 (remote) ...
11:28:15.605: debug : doRemoteOpen:535 : proceeding with name =
qemu:///session
11:28:15.608: debug : initialise_gnutls:1101 : loading CA file
//etc/pki/CA/cacert.pem
11:28:15.608: debug : initialise_gnutls:1114 : loading client cert and key
from files //etc/pki/libvirt/clientcert.pem and
//etc/pki/libvirt/private/clientkey.pem
11:28:15.703: debug : remoteIO:7421 : Do proc=66 serial=0 length=28
wait=(nil)
11:28:15.703: debug : remoteIO:7483 : We have the buck 66 0xb7d3e008
0xb7d3e008
11:28:15.709: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 64 total (60 more)
11:28:15.710: debug : remoteIOEventLoop:7347 : Giving up the buck 66
0xb7d3e008 (nil)
11:28:15.710: debug : remoteIO:7514 : All done with our call 66 (nil)
0xb7d3e008
11:28:15.710: debug : remoteIO:7421 : Do proc=1 serial=1 length=56
wait=(nil)
11:28:15.710: debug : remoteIO:7483 : We have the buck 1 0x8424f50 0x8424f50
11:28:15.712: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 56 total (52 more)
11:28:15.712: debug : remoteIOEventLoop:7347 : Giving up the buck 1
0x8424f50 (nil)
11:28:15.712: debug : remoteIO:7514 : All done with our call 1 (nil)
0x8424f50
11:28:15.715: debug : doRemoteOpen:850 : Adding Handler for remote events
11:28:15.715: debug : doRemoteOpen:857 : virEventAddHandle failed: No
addHandleImpl defined. continuing without events.
11:28:15.715: debug : do_open:1058 : driver 4 remote returned SUCCESS
11:28:15.715: debug : do_open:1078 : network driver 0 Test returned DECLINED
11:28:15.716: debug : do_open:1078 : network driver 1 VBOX returned DECLINED
11:28:15.716: debug : do_open:1078 : network driver 2 remote returned
SUCCESS
11:28:15.716: debug : do_open:1097 : interface driver 0 Test returned
DECLINED
11:28:15.716: debug : do_open:1097 : interface driver 1 remote returned
SUCCESS
11:28:15.716: debug : do_open:1117 : storage driver 0 Test returned DECLINED
11:28:15.716: debug : do_open:1117 : storage driver 1 VBOX returned DECLINED
11:28:15.716: debug : do_open:1117 : storage driver 2 remote returned
SUCCESS
11:28:15.716: debug : do_open:1137 : node driver 0 Test returned DECLINED
11:28:15.717: debug : do_open:1137 : node driver 1 remote returned SUCCESS
11:28:15.717: debug : do_open:1164 : secret driver 0 Test returned DECLINED
11:28:15.717: debug : do_open:1164 : secret driver 1 remote returned SUCCESS
11:28:15.717: debug : virDomainLookupByID:1739 : conn=0x83fc4b0, id=2
11:28:15.717: debug : remoteIO:7421 : Do proc=22 serial=2 length=32
wait=(nil)
11:28:15.717: debug : remoteIO:7483 : We have the buck 22 0x8424f50
0x8424f50
11:28:15.719: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 92 total (88 more)
11:28:15.719: debug : remoteIOEventLoop:7347 : Giving up the buck 22
0x8424f50 (nil)
11:28:15.719: debug : remoteIO:7514 : All done with our call 22 (nil)
0x8424f50
11:28:15.720: debug : virGetDomain:343 : New hash entry 0x841c630
11:28:15.720: debug : virDomainGetXMLDesc:2780 : domain=0x841c630, flags=0
11:28:15.720: debug : remoteIO:7421 : Do proc=14 serial=3 length=68
wait=(nil)
11:28:15.720: debug : remoteIO:7483 : We have the buck 14 0x8424f50
0x8424f50
11:28:15.723: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 1296 total (1292 more)
11:28:15.723: debug : remoteIOEventLoop:7347 : Giving up the buck 14
0x8424f50 (nil)
11:28:15.723: debug : remoteIO:7514 : All done with our call 14 (nil)
0x8424f50
11:28:15.724: debug : virDomainGetName:2431 : domain=0x841c630
11:28:15.724: debug : virDomainFree:1969 : domain=0x841c630
11:28:15.724: debug : virUnrefDomain:420 : unref domain 0x841c630 CloneWinXp
1
11:28:15.725: debug : virReleaseDomain:374 : release domain 0x841c630
CloneWinXp
11:28:15.725: debug : virReleaseDomain:390 : unref connection 0x83fc4b0 2
11:28:15.725: debug : virConnectClose:1291 : conn=0x83fc4b0
11:28:15.725: debug : virUnrefConnect:257 : unref connection 0x83fc4b0 1
11:28:15.725: debug : remoteIO:7421 : Do proc=2 serial=4 length=28
wait=(nil)
11:28:15.725: debug : remoteIO:7483 : We have the buck 2 0x8424f50 0x8424f50
11:28:15.727: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 56 total (52 more)
11:28:15.757: debug : remoteIOEventLoop:7347 : Giving up the buck 2
0x8424f50 (nil)
11:28:15.757: debug : remoteIO:7514 : All done with our call 2 (nil)
0x8424f50
11:28:15.758: debug : virReleaseConnect:214 : release connection 0x83fc4b0

Then i tried on my windows machine

URI that i used:
> virt-viewer.exe -c qemu://FC11-KVM/session 2

and this is the result that i got:

11:35:01.621: debug : virInitialize:294 : register drivers
11:35:01.626: debug : virRegisterDriver:735 : registering Test as driver 0
11:35:01.626: debug : virRegisterNetworkDriver:604 : registering Test as
network
 driver 0
11:35:01.626: debug : virRegisterInterfaceDriver:635 : registering Test as
inter
face driver 0
11:35:01.626: debug : virRegisterStorageDriver:666 : registering Test as
storage
 driver 0
11:35:01.627: debug : virRegisterDeviceMonitor:697 : registering Test as
device
driver 0
11:35:01.627: debug : virRegisterDriver:735 : registering ESX as driver 1
11:35:01.627: debug : virRegisterDriver:735 : registering remote as driver 2
11:35:01.627: debug : virRegisterNetworkDriver:604 : registering remote as
netwo
rk driver 1
11:35:01.627: debug : virRegisterInterfaceDriver:635 : registering remote as
int
erface driver 1
11:35:01.627: debug : virRegisterStorageDriver:666 : registering remote as
stora
ge driver 1
11:35:01.628: debug : virRegisterDeviceMonitor:697 : registering remote as
devic
e driver 1
11:35:01.635: debug : virConnectOpenAuth:1214 :
name=qemu://FC11-KVM/session, au
th=0022FD88, flags=1
11:35:01.639: debug : do_open:1001 : name "qemu://FC11-KVM/session" to URI
compo
nents:
  scheme qemu
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
11:35:01.646: debug : do_open:1011 : trying driver 0 (Test) ...
11:35:01.648: debug : do_open:1017 : driver 0 Test returned DECLINED
11:35:01.650: debug : do_open:1011 : trying driver 1 (ESX) ...
11:35:01.652: debug : do_open:1017 : driver 1 ESX returned DECLINED
11:35:01.653: debug : do_open:1011 : trying driver 2 (remote) ...
11:35:01.656: debug : doRemoteOpen:533 : proceeding with name =
qemu:///session
11:35:01.672: debug : initialise_gnutls:1099 : loading CA file
/usr/i686-pc-ming
w32/sys-root/mingw/etc/pki/CA/cacert.pem
11:35:01.677: debug : initialise_gnutls:1112 : loading client cert and key
from
files /usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/clientcert.pem and
/us
r/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem
11:35:01.697: debug : do_open:1017 : driver 2 remote returned ERROR
11:35:01.698: debug : virUnrefConnect:232 : unref connection 0263B068 1
11:35:01.700: debug : virReleaseConnect:191 : release connection 0263B068
unable to connect to libvirt qemu://FC11-KVM/session

tried with different URI on windows:
> virt-viewer.exe -c qemu+tcp://FC11-KVM/session 2

Result:

11:45:36.054: debug : virInitialize:294 : register drivers
11:45:36.060: debug : virRegisterDriver:735 : registering Test as driver 0
11:45:36.060: debug : virRegisterNetworkDriver:604 : registering Test as
network
 driver 0
11:45:36.060: debug : virRegisterInterfaceDriver:635 : registering Test as
inter
face driver 0
11:45:36.060: debug : virRegisterStorageDriver:666 : registering Test as
storage
 driver 0
11:45:36.060: debug : virRegisterDeviceMonitor:697 : registering Test as
device
driver 0
11:45:36.060: debug : virRegisterDriver:735 : registering ESX as driver 1
11:45:36.060: debug : virRegisterDriver:735 : registering remote as driver 2
11:45:36.060: debug : virRegisterNetworkDriver:604 : registering remote as
netwo
rk driver 1
11:45:36.060: debug : virRegisterInterfaceDriver:635 : registering remote as
int
erface driver 1
11:45:36.061: debug : virRegisterStorageDriver:666 : registering remote as
stora
ge driver 1
11:45:36.061: debug : virRegisterDeviceMonitor:697 : registering remote as
devic
e driver 1
11:45:36.068: debug : virConnectOpenAuth:1214 :
name=qemu+tcp://FC11-KVM/session
, auth=0022FD88, flags=1
11:45:36.071: debug : do_open:1001 : name "qemu+tcp://FC11-KVM/session" to
URI c
omponents:
  scheme qemu+tcp
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
11:45:36.080: debug : do_open:1011 : trying driver 0 (Test) ...
11:45:36.083: debug : do_open:1017 : driver 0 Test returned DECLINED
11:45:36.085: debug : do_open:1011 : trying driver 1 (ESX) ...
11:45:36.087: debug : do_open:1017 : driver 1 ESX returned DECLINED
11:45:36.089: debug : do_open:1011 : trying driver 2 (remote) ...
11:45:36.091: debug : doRemoteOpen:533 : proceeding with name =
qemu:///session
11:45:36.106: debug : remoteIO:7078 : Do proc=66 serial=0 length=28
wait=0000000
0
11:45:36.109: debug : remoteIO:7140 : We have the buck 66 029BDFC8 029BDFC8
11:45:36.114: debug : remoteIODecodeMessageLength:6689 : Got length, now
need 64
 total (60 more)
11:45:36.118: debug : remoteIOEventLoop:7004 : Giving up the buck 66
029BDFC8 00
000000
11:45:36.120: debug : remoteIO:7171 : All done with our call 66 00000000
029BDFC
8
11:45:36.126: debug : remoteIO:7078 : Do proc=1 serial=1 length=56
wait=00000000
11:45:36.128: debug : remoteIO:7140 : We have the buck 1 029BDFC8 029BDFC8
11:45:36.134: debug : remoteIODecodeMessageLength:6689 : Got length, now
need 56
 total (52 more)
11:45:36.137: debug : remoteIOEventLoop:7004 : Giving up the buck 1 029BDFC8
000
00000
11:45:36.139: debug : remoteIO:7171 : All done with our call 1 00000000
029BDFC8
11:45:36.141: debug : doRemoteOpen:848 : Adding Handler for remote events
11:45:36.143: debug : doRemoteOpen:858 : Adding Timeout for remote event
queue f
lushing
11:45:36.146: debug : do_open:1017 : driver 2 remote returned SUCCESS
11:45:36.148: debug : do_open:1037 : network driver 0 Test returned DECLINED
11:45:36.149: debug : do_open:1037 : network driver 1 remote returned
SUCCESS
11:45:36.151: debug : do_open:1056 : interface driver 0 Test returned
DECLINED
11:45:36.153: debug : do_open:1056 : interface driver 1 remote returned
SUCCESS
11:45:36.155: debug : do_open:1076 : storage driver 0 Test returned DECLINED
11:45:36.157: debug : do_open:1076 : storage driver 1 remote returned
SUCCESS
11:45:36.158: debug : do_open:1096 : node driver 0 Test returned DECLINED
11:45:36.160: debug : do_open:1096 : node driver 1 remote returned SUCCESS
11:45:36.249: debug : virDomainLookupByID:1692 : conn=0297A3A0, id=2
11:45:36.252: debug : remoteIO:7078 : Do proc=22 serial=2 length=32
wait=0000000
0
11:45:36.254: debug : remoteIO:7140 : We have the buck 22 03EF6858 03EF6858

Regards
Anuj

On Thu, Sep 24, 2009 at 6:54 PM, Richard W.M. Jones wrote:
> On Thu, Sep 24, 2009 at 06:41:03PM +0530, anuj rampal wrote:
> > But with TLS there was some certificate issue but after resolving this
> > issue, im still not able to connect to the libvirt
> > this is what it says:
> >
> > virsh.exe -c qemu://FC11-KVM/session
> > error: unable to connect to libvirtd at 'FC11-KVM': errno=22
> > error: failed to connect to the hypervisor
> >
> > this is what it says...???? (this is from my vista machine)
>
> Apparently "errno 22" is EINVAL.
>
> That doesn't help much.  I really need you to set the LIBVIRT_DEBUG
> environment variable to 1 on order to show the full messages, and then
> continue with the tests as outlined in the previous email.
>
> http://support.microsoft.com/kb/310519
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/

[Richard W.M. Jones]

On Fri, Sep 25, 2009 at 11:57:35AM +0530, anuj rampal wrote:
> Then i tried on my windows machine
>
> URI that i used:
> virt-viewer.exe -c qemu://FC11-KVM/session 2
>
> and this is the result that i got:

[...]
> 11:35:01.672: debug : initialise_gnutls:1099 : loading CA file
> /usr/i686-pc-ming
> w32/sys-root/mingw/etc/pki/CA/cacert.pem
> 11:35:01.677: debug : initialise_gnutls:1112 : loading client cert and key
> from
> files /usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/clientcert.pem and
> /us
> r/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem
> 11:35:01.697: debug : do_open:1017 : driver 2 remote returned ERROR
> 11:35:01.698: debug : virUnrefConnect:232 : unref connection 0263B068 1
> 11:35:01.700: debug : virReleaseConnect:191 : release connection 0263B068
> unable to connect to libvirt qemu://FC11-KVM/session

So the problem is that as you can see from reading the messages, it
can't load the client key file (from
/usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem).

This path is compiled into libvirt, so the only way to change it is to
recompile libvirt with sysconfdir set to a more suitable path:

./configure --sysconfdir=/etc

for example (and create /etc/pki ... on Windows).
> tried with different URI on windows:
> virt-viewer.exe -c qemu+tcp://FC11-KVM/session 2

[...]

This worked, obviously because it's not using GnuTLS for encryption.

Rich.

[anuj rampal]

Hi,
> 11:35:01.672: debug : initialise_gnutls:1099 : loading CA file
> /usr/i686-pc-ming
> w32/sys-root/mingw/etc/pki/CA/cacert.pem
> 11:35:01.677: debug : initialise_gnutls:1112 : loading client cert and key
> from
> files /usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/clientcert.pem

and
> /us
> r/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem
> 11:35:01.697: debug : do_open:1017 : driver 2 remote returned ERROR

On windows virt-viewer take these from certificates for
"Z:\usr\i686-pc-mingw32\sys-root\mingw\etc\pki" which i guess is hardcoded
in the code...(dont know y)
i tried "./configure --sysconfdir=C:\pki"
but this didnot work...

the certificates that i user here have to be correct because.. these
certificates are the same when i connect from a different linux machine
there i dont get the ERROR message. but still nothing happens.

These are the results when i tried running virt-viewer using the following
URI:

1.
LIBVIRT_DEBUG=1 virt-viewer -c qemu://FC11-KVM/session 2

result:
here i dont think there is an issue with the certificates:
what happens here is a small window pops up with the message "Conneting to
vnc server" thats it and then the message goes.

00:35:46.089: debug : virInitialize:279 : register drivers
00:35:46.090: debug : virRegisterDriver:776 : registering Test as driver 0
00:35:46.090: debug : virRegisterNetworkDriver:614 : registering Test as
network driver 0
00:35:46.090: debug : virRegisterInterfaceDriver:645 : registering Test as
interface driver 0
00:35:46.090: debug : virRegisterStorageDriver:676 : registering Test as
storage driver 0
00:35:46.090: debug : virRegisterDeviceMonitor:707 : registering Test as
device driver 0
00:35:46.090: debug : virRegisterSecretDriver:738 : registering Test as
secret driver 0
00:35:46.090: debug : virRegisterDriver:776 : registering OPENVZ as driver 1
00:35:46.091: debug : vboxRegister:101 : VBoxCGlueInit failed, using dummy
driver
00:35:46.091: debug : virRegisterDriver:776 : registering VBOX as driver 2
00:35:46.091: debug : virRegisterNetworkDriver:614 : registering VBOX as
network driver 1
00:35:46.092: debug : virRegisterStorageDriver:676 : registering VBOX as
storage driver 1
00:35:46.092: debug : virRegisterDriver:776 : registering ESX as driver 3
00:35:46.092: debug : virRegisterDriver:776 : registering remote as driver 4
00:35:46.092: debug : virRegisterNetworkDriver:614 : registering remote as
network driver 2
00:35:46.092: debug : virRegisterInterfaceDriver:645 : registering remote as
interface driver 1
00:35:46.092: debug : virRegisterStorageDriver:676 : registering remote as
storage driver 2
00:35:46.092: debug : virRegisterDeviceMonitor:707 : registering remote as
device driver 1
00:35:46.092: debug : virRegisterSecretDriver:738 : registering remote as
secret driver 1
00:35:46.093: debug : virConnectOpenAuth:1273 :
name=qemu://FC11-KVM/session, auth=0xbfce11c8, flags=1
00:35:46.093: debug : do_open:1042 : name "qemu://FC11-KVM/session" to URI
components:
  scheme qemu
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
00:35:46.094: debug : do_open:1052 : trying driver 0 (Test) ...
00:35:46.094: debug : do_open:1058 : driver 0 Test returned DECLINED
00:35:46.094: debug : do_open:1052 : trying driver 1 (OPENVZ) ...
00:35:46.094: debug : do_open:1058 : driver 1 OPENVZ returned DECLINED
00:35:46.094: debug : do_open:1052 : trying driver 2 (VBOX) ...
00:35:46.094: debug : do_open:1058 : driver 2 VBOX returned DECLINED
00:35:46.095: debug : do_open:1052 : trying driver 3 (ESX) ...
00:35:46.095: debug : do_open:1058 : driver 3 ESX returned DECLINED
00:35:46.095: debug : do_open:1052 : trying driver 4 (remote) ...
00:35:46.095: debug : doRemoteOpen:535 : proceeding with name =
qemu:///session
00:35:46.099: debug : initialise_gnutls:1101 : loading CA file
//etc/pki/CA/cacert.pem
00:35:46.107: debug : initialise_gnutls:1114 : loading client cert and key
from files //etc/pki/libvirt/clientcert.pem and
//etc/pki/libvirt/private/clientkey.pem
00:35:46.213: debug : remoteIO:7421 : Do proc=66 serial=0 length=28
wait=(nil)
00:35:46.213: debug : remoteIO:7483 : We have the buck 66 0xb7d2f008
0xb7d2f008
00:35:46.215: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 64 total (60 more)
00:35:46.215: debug : remoteIOEventLoop:7347 : Giving up the buck 66
0xb7d2f008 (nil)
00:35:46.216: debug : remoteIO:7514 : All done with our call 66 (nil)
0xb7d2f008
00:35:46.216: debug : remoteIO:7421 : Do proc=1 serial=1 length=56
wait=(nil)
00:35:46.216: debug : remoteIO:7483 : We have the buck 1 0xa07f620 0xa07f620
00:35:46.217: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 56 total (52 more)
00:35:46.217: debug : remoteIOEventLoop:7347 : Giving up the buck 1
0xa07f620 (nil)
00:35:46.218: debug : remoteIO:7514 : All done with our call 1 (nil)
0xa07f620
00:35:46.218: debug : doRemoteOpen:850 : Adding Handler for remote events
00:35:46.218: debug : doRemoteOpen:860 : Adding Timeout for remote event
queue flushing
00:35:46.218: debug : do_open:1058 : driver 4 remote returned SUCCESS
00:35:46.218: debug : do_open:1078 : network driver 0 Test returned DECLINED
00:35:46.218: debug : do_open:1078 : network driver 1 VBOX returned DECLINED
00:35:46.218: debug : do_open:1078 : network driver 2 remote returned
SUCCESS
00:35:46.218: debug : do_open:1097 : interface driver 0 Test returned
DECLINED
00:35:46.218: debug : do_open:1097 : interface driver 1 remote returned
SUCCESS
00:35:46.218: debug : do_open:1117 : storage driver 0 Test returned DECLINED
00:35:46.219: debug : do_open:1117 : storage driver 1 VBOX returned DECLINED
00:35:46.219: debug : do_open:1117 : storage driver 2 remote returned
SUCCESS
00:35:46.219: debug : do_open:1137 : node driver 0 Test returned DECLINED
00:35:46.219: debug : do_open:1137 : node driver 1 remote returned SUCCESS
00:35:46.219: debug : do_open:1164 : secret driver 0 Test returned DECLINED
00:35:46.219: debug : do_open:1164 : secret driver 1 remote returned SUCCESS
00:35:46.281: debug : virDomainLookupByID:1739 : conn=0xa051928, id=2
00:35:46.282: debug : remoteIO:7421 : Do proc=22 serial=2 length=32
wait=(nil)
00:35:46.282: debug : remoteIO:7483 : We have the buck 22 0xa17fa00
0xa17fa00
00:35:46.283: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 92 total (88 more)
00:35:46.283: debug : remoteIOEventLoop:7347 : Giving up the buck 22
0xa17fa00 (nil)
00:35:46.284: debug : remoteIO:7514 : All done with our call 22 (nil)
0xa17fa00
00:35:46.284: debug : virGetDomain:343 : New hash entry 0xa17cfd8
00:35:46.284: debug : virDomainGetInfo:2732 : domain=0xa17cfd8,
info=0xbfce1140
00:35:46.285: debug : remoteIO:7421 : Do proc=16 serial=3 length=64
wait=(nil)
00:35:46.285: debug : remoteIO:7483 : We have the buck 16 0xa17fa00
0xa17fa00
00:35:46.287: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 88 total (84 more)
00:35:46.287: debug : remoteIOEventLoop:7347 : Giving up the buck 16
0xa17fa00 (nil)
00:35:46.287: debug : remoteIO:7514 : All done with our call 16 (nil)
0xa17fa00
00:35:46.287: debug : virDomainGetXMLDesc:2780 : domain=0xa17cfd8, flags=0
00:35:46.287: debug : remoteIO:7421 : Do proc=14 serial=4 length=68
wait=(nil)
00:35:46.287: debug : remoteIO:7483 : We have the buck 14 0xa17fa00
0xa17fa00
00:35:46.290: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 1296 total (1292 more)
00:35:46.290: debug : remoteIOEventLoop:7347 : Giving up the buck 14
0xa17fa00 (nil)
00:35:46.290: debug : remoteIO:7514 : All done with our call 14 (nil)
0xa17fa00
00:35:46.291: debug : virDomainGetName:2431 : domain=0xa17cfd8
00:35:46.291: debug : virDomainFree:1969 : domain=0xa17cfd8
00:35:46.291: debug : virUnrefDomain:420 : unref domain 0xa17cfd8 CloneWinXp
1
00:35:46.292: debug : virReleaseDomain:374 : release domain 0xa17cfd8
CloneWinXp
00:35:46.292: debug : virReleaseDomain:390 : unref connection 0xa051928 2
00:35:46.292: debug : virConnectDomainEventRegister:8637 : conn=0xa051928,
cb=0x804d1e0, opaque=0xa056468, freecb=(nil)
00:35:46.292: debug : remoteIO:7421 : Do proc=105 serial=5 length=28
wait=(nil)
00:35:46.292: debug : remoteIO:7483 : We have the buck 105 0xa1c0730
0xa1c0730
00:35:46.294: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 60 total (56 more)
00:35:46.294: debug : remoteIOEventLoop:7347 : Giving up the buck 105
0xa1c0730 (nil)
00:35:46.294: debug : remoteIO:7514 : All done with our call 105 (nil)
0xa1c0730

2.
LIBVIRT_DEBUG=1 virt-viewer -c qemu+tcp://FC11-KVM/session 2

result:
same thing happens here. the window pops up and goes.

00:34:48.829: debug : virInitialize:279 : register drivers
00:34:48.830: debug : virRegisterDriver:776 : registering Test as driver 0
00:34:48.830: debug : virRegisterNetworkDriver:614 : registering Test as
network driver 0
00:34:48.830: debug : virRegisterInterfaceDriver:645 : registering Test as
interface driver 0
00:34:48.830: debug : virRegisterStorageDriver:676 : registering Test as
storage driver 0
00:34:48.830: debug : virRegisterDeviceMonitor:707 : registering Test as
device driver 0
00:34:48.830: debug : virRegisterSecretDriver:738 : registering Test as
secret driver 0
00:34:48.830: debug : virRegisterDriver:776 : registering OPENVZ as driver 1
00:34:48.830: debug : vboxRegister:101 : VBoxCGlueInit failed, using dummy
driver
00:34:48.830: debug : virRegisterDriver:776 : registering VBOX as driver 2
00:34:48.830: debug : virRegisterNetworkDriver:614 : registering VBOX as
network driver 1
00:34:48.830: debug : virRegisterStorageDriver:676 : registering VBOX as
storage driver 1
00:34:48.830: debug : virRegisterDriver:776 : registering ESX as driver 3
00:34:48.831: debug : virRegisterDriver:776 : registering remote as driver 4
00:34:48.831: debug : virRegisterNetworkDriver:614 : registering remote as
network driver 2
00:34:48.831: debug : virRegisterInterfaceDriver:645 : registering remote as
interface driver 1
00:34:48.831: debug : virRegisterStorageDriver:676 : registering remote as
storage driver 2
00:34:48.831: debug : virRegisterDeviceMonitor:707 : registering remote as
device driver 1
00:34:48.831: debug : virRegisterSecretDriver:738 : registering remote as
secret driver 1
00:34:48.831: debug : virConnectOpenAuth:1273 :
name=qemu+tcp://FC11-KVM/session, auth=0xbfc34918, flags=1
00:34:48.831: debug : do_open:1042 : name "qemu+tcp://FC11-KVM/session" to
URI components:
  scheme qemu+tcp
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
00:34:48.831: debug : do_open:1052 : trying driver 0 (Test) ...
00:34:48.831: debug : do_open:1058 : driver 0 Test returned DECLINED
00:34:48.831: debug : do_open:1052 : trying driver 1 (OPENVZ) ...
00:34:48.831: debug : do_open:1058 : driver 1 OPENVZ returned DECLINED
00:34:48.831: debug : do_open:1052 : trying driver 2 (VBOX) ...
00:34:48.831: debug : do_open:1058 : driver 2 VBOX returned DECLINED
00:34:48.831: debug : do_open:1052 : trying driver 3 (ESX) ...
00:34:48.831: debug : do_open:1058 : driver 3 ESX returned DECLINED
00:34:48.831: debug : do_open:1052 : trying driver 4 (remote) ...
00:34:48.831: debug : doRemoteOpen:535 : proceeding with name =
qemu:///session
00:34:48.835: debug : remoteIO:7421 : Do proc=66 serial=0 length=28
wait=(nil)
00:34:48.835: debug : remoteIO:7483 : We have the buck 66 0xb7c81008
0xb7c81008
00:34:48.838: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 64 total (60 more)
00:34:48.838: debug : remoteIOEventLoop:7347 : Giving up the buck 66
0xb7c81008 (nil)
00:34:48.838: debug : remoteIO:7514 : All done with our call 66 (nil)
0xb7c81008
00:34:48.838: debug : remoteIO:7421 : Do proc=1 serial=1 length=56
wait=(nil)
00:34:48.839: debug : remoteIO:7483 : We have the buck 1 0x894e658 0x894e658
00:34:48.839: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 56 total (52 more)
00:34:48.839: debug : remoteIOEventLoop:7347 : Giving up the buck 1
0x894e658 (nil)
00:34:48.839: debug : remoteIO:7514 : All done with our call 1 (nil)
0x894e658
00:34:48.839: debug : doRemoteOpen:850 : Adding Handler for remote events
00:34:48.839: debug : doRemoteOpen:860 : Adding Timeout for remote event
queue flushing
00:34:48.839: debug : do_open:1058 : driver 4 remote returned SUCCESS
00:34:48.839: debug : do_open:1078 : network driver 0 Test returned DECLINED
00:34:48.839: debug : do_open:1078 : network driver 1 VBOX returned DECLINED
00:34:48.839: debug : do_open:1078 : network driver 2 remote returned
SUCCESS
00:34:48.839: debug : do_open:1097 : interface driver 0 Test returned
DECLINED
00:34:48.839: debug : do_open:1097 : interface driver 1 remote returned
SUCCESS
00:34:48.839: debug : do_open:1117 : storage driver 0 Test returned DECLINED
00:34:48.839: debug : do_open:1117 : storage driver 1 VBOX returned DECLINED
00:34:48.839: debug : do_open:1117 : storage driver 2 remote returned
SUCCESS
00:34:48.839: debug : do_open:1137 : node driver 0 Test returned DECLINED
00:34:48.839: debug : do_open:1137 : node driver 1 remote returned SUCCESS
00:34:48.840: debug : do_open:1164 : secret driver 0 Test returned DECLINED
00:34:48.840: debug : do_open:1164 : secret driver 1 remote returned SUCCESS
00:34:48.907: debug : virDomainLookupByID:1739 : conn=0x8944928, id=2
00:34:48.907: debug : remoteIO:7421 : Do proc=22 serial=2 length=32
wait=(nil)
00:34:48.907: debug : remoteIO:7483 : We have the buck 22 0x8a50a00
0x8a50a00
00:34:48.908: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 92 total (88 more)
00:34:48.909: debug : remoteIOEventLoop:7347 : Giving up the buck 22
0x8a50a00 (nil)
00:34:48.909: debug : remoteIO:7514 : All done with our call 22 (nil)
0x8a50a00
00:34:48.909: debug : virGetDomain:343 : New hash entry 0x8a4f3b0
00:34:48.909: debug : virDomainGetInfo:2732 : domain=0x8a4f3b0,
info=0xbfc34890
00:34:48.910: debug : remoteIO:7421 : Do proc=16 serial=3 length=64
wait=(nil)
00:34:48.910: debug : remoteIO:7483 : We have the buck 16 0x8a50a00
0x8a50a00
00:34:48.912: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 88 total (84 more)
00:34:48.912: debug : remoteIOEventLoop:7347 : Giving up the buck 16
0x8a50a00 (nil)
00:34:48.912: debug : remoteIO:7514 : All done with our call 16 (nil)
0x8a50a00
00:34:48.912: debug : virDomainGetXMLDesc:2780 : domain=0x8a4f3b0, flags=0
00:34:48.912: debug : remoteIO:7421 : Do proc=14 serial=4 length=68
wait=(nil)
00:34:48.912: debug : remoteIO:7483 : We have the buck 14 0x8a50a00
0x8a50a00
00:34:48.914: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 1296 total (1292 more)
00:34:48.914: debug : remoteIOEventLoop:7347 : Giving up the buck 14
0x8a50a00 (nil)
00:34:48.914: debug : remoteIO:7514 : All done with our call 14 (nil)
0x8a50a00
00:34:48.915: debug : virDomainGetName:2431 : domain=0x8a4f3b0
00:34:48.915: debug : virDomainFree:1969 : domain=0x8a4f3b0
00:34:48.915: debug : virUnrefDomain:420 : unref domain 0x8a4f3b0 CloneWinXp
1
00:34:48.915: debug : virReleaseDomain:374 : release domain 0x8a4f3b0
CloneWinXp
00:34:48.915: debug : virReleaseDomain:390 : unref connection 0x8944928 2
00:34:48.915: debug : virConnectDomainEventRegister:8637 : conn=0x8944928,
cb=0x804d1e0, opaque=0x8949468, freecb=(nil)
00:34:48.915: debug : remoteIO:7421 : Do proc=105 serial=5 length=28
wait=(nil)
00:34:48.915: debug : remoteIO:7483 : We have the buck 105 0x8a53850
0x8a53850
00:34:48.916: debug : remoteIODecodeMessageLength:7032 : Got length, now
need 60 total (56 more)
00:34:48.916: debug : remoteIOEventLoop:7347 : Giving up the buck 105
0x8a53850 (nil)
00:34:48.916: debug : remoteIO:7514 : All done with our call 105 (nil)
0x8a53850

When i tried these same commands on the same machine where the libvirtd is
running:

it works fine. with
qemu+tcp:///session 2

qemu:///session 2

i also tried to debug the virt-viewer-0.2.0 code.

the only thing that i could find out was that in src/main.c in function int
main(.....)

line 97 : gtk_main();

after reaching this line

1. On the same machine the code hangs and the vnc display is shown and i can
view my guest machine.

2. On the remote machine it doesnot stops here and comes out with the
message on the popup saying connecting to vnc server.

------------------------

On windows im still facing the problem with certificates because the same
certificates works on remote linux machine.

but using "qemu+tcp://FC11-KVM/session 2"... atlease a new window pops up
which does not respond...

Do we have to do any configuration on libvirtd to make virt-viewer to work
over tcp and tls because it works fine from a remote linux machine over ssh.

------------------------

has any1 have got any success running virt-viewer on windows...??

Regards
Anuj

On Fri, Sep 25, 2009 at 5:32 PM, Richard W.M. Jones wrote:
> On Fri, Sep 25, 2009 at 11:57:35AM +0530, anuj rampal wrote:
> > Then i tried on my windows machine
> >
> > URI that i used:
> > virt-viewer.exe -c qemu://FC11-KVM/session 2
> >
> > and this is the result that i got:
>
> [...]
> > 11:35:01.672: debug : initialise_gnutls:1099 : loading CA file
> > /usr/i686-pc-ming
> > w32/sys-root/mingw/etc/pki/CA/cacert.pem
> > 11:35:01.677: debug : initialise_gnutls:1112 : loading client cert and
>
> key
> > from
> > files /usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/clientcert.pem
>
> and
> > /us
> > r/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem
> > 11:35:01.697: debug : do_open:1017 : driver 2 remote returned ERROR
> > 11:35:01.698: debug : virUnrefConnect:232 : unref connection 0263B068 1
> > 11:35:01.700: debug : virReleaseConnect:191 : release connection 0263B068
> > unable to connect to libvirt qemu://FC11-KVM/session
>
> So the problem is that as you can see from reading the messages, it
> can't load the client key file (from
> /usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem).
>
> This path is compiled into libvirt, so the only way to change it is to
> recompile libvirt with sysconfdir set to a more suitable path:
>
> ./configure --sysconfdir=/etc
>
> for example (and create /etc/pki ... on Windows).
> > tried with different URI on windows:
> > virt-viewer.exe -c qemu+tcp://FC11-KVM/session 2
>
> [...]
>
> This worked, obviously because it's not using GnuTLS for encryption.
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
> See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html

[Richard W.M. Jones]

On Wed, Sep 30, 2009 at 09:02:59PM +0530, anuj rampal wrote:
> i tried "./configure --sysconfdir=C:\pki"
> but this didnot work...

When you say this "did not work", how did it fail?  The clue is
usually in the error message.

In any case, you almost certainly can't just write C:\pki\ because \
is an escape character.  Maybe you can double them, or use forward
slashes instead.
> LIBVIRT_DEBUG=1 virt-viewer -c qemu://FC11-KVM/session 2

It's really not helpful to use virt-viewer to test.  Test using a
simple tool like virsh.  Get that working first.  Once you understand
what the problem was, *only then* try virt-viewer.
> Do we have to do any configuration on libvirtd to make virt-viewer to work
> over tcp and tls because it works fine from a remote linux machine over ssh.

You can also disable encryption in libvirtd:

http://libvirt.org/remote.html#Remote_libvirtd_configuration

or read the libvirtd.conf file.

Rich.

[anuj rampal]

> i tried "./configure --sysconfdir=C:\pki"
> but this didnot work...

When you say this "did not work", how did it fail?  The clue is
usually in the error message.

when i did --sysconfdir="C:\pki" I expected that i have keep my
certificates under this directory(correct me if i'm wrong).
But it was still taking the certificates from
"Z:\usr\i686-pc-mingw\sys-confic\mingw\etc\pki" (in Windows).

--------------------------

Regarding virsh:

*virsh on linux mahine:*

URI tried from a remote linux mahine:

virsh -c qemu+tcp://FC11-KVM/session

virsh -c qemu://FC11-KVM/session

virsh -c qemu+ssh://FC11-KVM/session

virsh -c qemu+unix://FC11-KVM/session

all of these work fine
*
virsh on windows:*

on windows the supported URIs are:

virsh.exe -c qemu+tcp://FC11-KVM/session

virsh.exe -c qemu://FC11-KVM/session

URI "qemu+tcp://FC11-KVM/session" works fine. It gets connected and i can
call all the functions.
I have also written a small code on C#.net and i use this URI
(qemu+tcp://FC11-KVM/session) to connect to libvirt and call the functions
and it works fine without any problem.

Now the problem again comes with URI : virsh.exe -c qemu://FC11-KVM/session

when i rum me code using the above URI
this is what the error message that it gives:
Cannot access CA certificate
'/usr/i686-pc-mingw32/sys-root/mingw/etc/pki/CA/cacert.pem' : errno=2

So basically i need to change the the path it is looking in.....

On Wed, Sep 30, 2009 at 9:51 PM, Richard W.M. Jones wrote:
> On Wed, Sep 30, 2009 at 09:02:59PM +0530, anuj rampal wrote:
> > i tried "./configure --sysconfdir=C:\pki"
> > but this didnot work...
>
> When you say this "did not work", how did it fail?  The clue is
> usually in the error message.
>
> In any case, you almost certainly can't just write C:\pki\ because \
> is an escape character.  Maybe you can double them, or use forward
> slashes instead.
> > LIBVIRT_DEBUG=1 virt-viewer -c qemu://FC11-KVM/session 2
>
> It's really not helpful to use virt-viewer to test.  Test using a
> simple tool like virsh.  Get that working first.  Once you understand
> what the problem was, *only then* try virt-viewer.
> > Do we have to do any configuration on libvirtd to make virt-viewer to
>
> work
> > over tcp and tls because it works fine from a remote linux machine over
>
> ssh.
>
> You can also disable encryption in libvirtd:
>
> http://libvirt.org/remote.html#Remote_libvirtd_configuration
>
> or read the libvirtd.conf file.
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones http://et.redhat.com/%7Erjones
> Read my programming blog: http://rwmj.wordpress.com
> Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
> http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

[Richard W.M. Jones]

On Thu, Oct 01, 2009 at 02:00:49PM +0530, anuj rampal wrote:
> > i tried "./configure --sysconfdir=C:\pki"
> > but this didnot work...
>
> When you say this "did not work", how did it fail?  The clue is
> usually in the error message.
>
> when i did --sysconfdir="C:\pki" I expected that i have keep my
> certificates under this directory(correct me if i'm wrong).
> But it was still taking the certificates from
> "Z:\usr\i686-pc-mingw\sys-confic\mingw\etc\pki" (in Windows).

But what were the messages in the configure step?

Rich.

[anuj rampal]

Hi,

But what were the messages in the configure step?

As i said that virt-viewer takes the certificates from
"Z:\usr\i686-pc-mingw32\sys-root\mingw\etc\pki..." path in windows.

This is what i tried:

1. when I do not keep the certificates on this path. This is the result that
I get.

URI: virt-viewer.exe -c qemu://FC11-KVM/session 1

This is the result:
14:53:35.044: debug : virInitialize:294 : register drivers
14:53:35.050: debug : virRegisterDriver:735 : registering Test as driver 0
14:53:35.051: debug : virRegisterNetworkDriver:604 : registering Test as
network
 driver 0
14:53:35.051: debug : virRegisterInterfaceDriver:635 : registering Test as
inter
face driver 0
14:53:35.051: debug : virRegisterStorageDriver:666 : registering Test as
storage
 driver 0
14:53:35.052: debug : virRegisterDeviceMonitor:697 : registering Test as
device
driver 0
14:53:35.052: debug : virRegisterDriver:735 : registering ESX as driver 1
14:53:35.052: debug : virRegisterDriver:735 : registering remote as driver 2
14:53:35.052: debug : virRegisterNetworkDriver:604 : registering remote as
netwo
rk driver 1
14:53:35.053: debug : virRegisterInterfaceDriver:635 : registering remote as
int
erface driver 1
14:53:35.053: debug : virRegisterStorageDriver:666 : registering remote as
stora
ge driver 1
14:53:35.053: debug : virRegisterDeviceMonitor:697 : registering remote as
devic
e driver 1
14:53:35.070: debug : virConnectOpenAuth:1214 :
name=qemu://FC11-KVM/session, au
th=0022FD88, flags=1
14:53:35.072: debug : do_open:1001 : name "qemu://FC11-KVM/session" to URI
compo
nents:
  scheme qemu
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
14:53:35.077: debug : do_open:1011 : trying driver 0 (Test) ...
14:53:35.078: debug : do_open:1017 : driver 0 Test returned DECLINED
14:53:35.083: debug : do_open:1011 : trying driver 1 (ESX) ...
14:53:35.084: debug : do_open:1017 : driver 1 ESX returned DECLINED
14:53:35.086: debug : do_open:1011 : trying driver 2 (remote) ...
14:53:35.087: debug : doRemoteOpen:533 : proceeding with name =
qemu:///session
14:53:35.104: debug : do_open:1017 : driver 2 remote returned ERROR
14:53:35.105: debug : virUnrefConnect:232 : unref connection 02ACA3A0 1
14:53:35.107: debug : virReleaseConnect:191 : release connection 02ACA3A0
unable to connect to libvirt qemu://FC11-KVM/session

2. When i again palce the certificates at this path. This is the result that
i get.

URI: virt-viewer.exe -c qemu://FC11-KVM/session 1

This is the result:

14:56:02.938: debug : virInitialize:294 : register drivers
14:56:02.944: debug : virRegisterDriver:735 : registering Test as driver 0
14:56:02.944: debug : virRegisterNetworkDriver:604 : registering Test as
network
 driver 0
14:56:02.944: debug : virRegisterInterfaceDriver:635 : registering Test as
inter
face driver 0
14:56:02.945: debug : virRegisterStorageDriver:666 : registering Test as
storage
 driver 0
14:56:02.949: debug : virRegisterDeviceMonitor:697 : registering Test as
device
driver 0
14:56:02.950: debug : virRegisterDriver:735 : registering ESX as driver 1
14:56:02.950: debug : virRegisterDriver:735 : registering remote as driver 2
14:56:02.950: debug : virRegisterNetworkDriver:604 : registering remote as
netwo
rk driver 1
14:56:02.951: debug : virRegisterInterfaceDriver:635 : registering remote as
int
erface driver 1
14:56:02.951: debug : virRegisterStorageDriver:666 : registering remote as
stora
ge driver 1
14:56:02.951: debug : virRegisterDeviceMonitor:697 : registering remote as
devic
e driver 1
14:56:02.960: debug : virConnectOpenAuth:1214 :
name=qemu://FC11-KVM/session, au
th=0022FD88, flags=1
14:56:02.962: debug : do_open:1001 : name "qemu://FC11-KVM/session" to URI
compo
nents:
  scheme qemu
  opaque (null)
  authority (null)
  server FC11-KVM
  user (null)
  port 0
  path /session
14:56:02.966: debug : do_open:1011 : trying driver 0 (Test) ...
14:56:02.970: debug : do_open:1017 : driver 0 Test returned DECLINED
14:56:02.972: debug : do_open:1011 : trying driver 1 (ESX) ...
14:56:02.973: debug : do_open:1017 : driver 1 ESX returned DECLINED
14:56:02.974: debug : do_open:1011 : trying driver 2 (remote) ...
14:56:02.976: debug : doRemoteOpen:533 : proceeding with name =
qemu:///session
14:56:02.993: debug : initialise_gnutls:1099 : loading CA file
/usr/i686-pc-ming
w32/sys-root/mingw/etc/pki/CA/cacert.pem
14:56:02.996: debug : initialise_gnutls:1112 : loading client cert and key
from
files /usr/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/clientcert.pem and
/us
r/i686-pc-mingw32/sys-root/mingw/etc/pki/libvirt/private/clientkey.pem
14:56:03.114: debug : do_open:1017 : driver 2 remote returned ERROR
14:56:03.115: debug : virUnrefConnect:232 : unref connection 025EA3A0 1
14:56:03.117: debug : virReleaseConnect:191 : release connection 025EA3A0
unable to connect to libvirt qemu://FC11-KVM/session

Regards
Anuj

On Thu, Oct 1, 2009 at 2:16 PM, Richard W.M. Jones wrote:
> On Thu, Oct 01, 2009 at 02:00:49PM +0530, anuj rampal wrote:
> > > i tried "./configure --sysconfdir=C:\pki"
> > > but this didnot work...
> >
> > When you say this "did not work", how did it fail?  The clue is
> > usually in the error message.
> >
> > when i did --sysconfdir="C:\pki" I expected that i have keep my
> > certificates under this directory(correct me if i'm wrong).
> > But it was still taking the certificates from
> > "Z:\usr\i686-pc-mingw\sys-confic\mingw\etc\pki" (in Windows).
>
> But what were the messages in the configure step?
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat
> http://et.redhat.com/~rjones
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/

[Anand Kumria]

Hi,

What's with the colours? Why are you making it harder to understand what was
said by who?

On Mon, Oct 5, 2009 at 10:27 AM, anuj rampal  wrote:
> Hi,

It would also be really useful if you kept the attribution lines, so we
could all see who had said what, when.

What Richard is asking you for is the output of the ./configure command.

What he hasn't asked, yet, is how porting libvirt and the virt-* utilis
helps you.

What is the actual end goal here? A "just for fun" experiment, in which case
you are probably better served by answers to your questions which lead you
to do the deeper debugging. Or a school project, in which case the same
applies.

Thanks,
Anand

[anuj rampal]

On Tue, Oct 6, 2009 at 5:01 AM, Anand Kumria  wrote:
> Hi,
>
> What's with the colours? Why are you making it harder to understand what
> was said by who?
> It would also be really useful if you kept the attribution lines, so we
> could all see who had said what, when.
>
> What Richard is asking you for is the output of the ./configure command.

These are the packages that are required: as given in the mingw32.spec file
mingw32-filesystem
mingw32-gtk2
mingw32-libvirt
mingw32-libxml2
mingw32-libglade2
mingw32-gtk-vnc
pkgconfig

These are all there..

[root@FC11-KVM ~]# rpm -qa | grep mingw32-filesystem
mingw32-filesystem-50-3.fc11.1.noarch
[root@FC11-KVM ~]# rpm -qa | grep mingw32-gtk2
mingw32-gtk2-2.16.6-1.fc11.noarch
mingw32-gtk2-static-2.16.6-1.fc11.noarch
[root@FC11-KVM ~]# rpm -qa | grep mingw32-libvirt
mingw32-libvirt-0.6.1-1.fc11.noarch
[root@FC11-KVM ~]# rpm -qa | grep mingw32-libxml2
mingw32-libxml2-2.7.4-1.fc11.noarch
mingw32-libxml2-static-2.7.4-1.fc11.noarch
[root@FC11-KVM ~]# rpm -qa | grep mingw32-libglade2
mingw32-libglade2-2.6.4-2.fc11.noarch
mingw32-libglade2-static-2.6.4-2.fc11.noarch
[root@FC11-KVM ~]# rpm -qa | grep mingw32-gtk-vnc
mingw32-gtk-vnc-0.3.8-5.fc11.noarch
[root@FC11-KVM ~]# rpm -qa | grep pkgconfig
pkgconfig-0.23-8.fc11.i586

-----------------------

this is how i configured the virt-viewer:

PKG_CONFIG_PATH="/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig"
CC="i686-pc-mingw32-gcc"  ./configure    --build=i386-pc-linux
--host=i686-pc-mingw32    --prefix="/usr/i686-pc-mingw32/sys-root/mingw"
--sysconfdir=C:\pki

and here is the result:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for i686-pc-mingw32-strip... i686-pc-mingw32-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i386-pc-linux-gnu
checking host system type... i686-pc-mingw32
checking for i686-pc-mingw32-gcc... i686-pc-mingw32-gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-mingw32-gcc accepts -g... yes
checking for i686-pc-mingw32-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of i686-pc-mingw32-gcc... gcc3
checking whether i686-pc-mingw32-gcc and cc understand -c and -o together...
yes
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by i686-pc-mingw32-gcc... /usr/i686-pc-mingw32/bin/ld
checking if the linker (/usr/i686-pc-mingw32/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)...
/usr/bin/i686-pc-mingw32-nm -B
checking the name lister (/usr/bin/i686-pc-mingw32-nm -B) interface... BSD
nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1966080
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/i686-pc-mingw32/bin/ld option to reload object files... -r
checking for i686-pc-mingw32-objdump... i686-pc-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive
import|^x86 DLL
checking for i686-pc-mingw32-ar... i686-pc-mingw32-ar
checking for i686-pc-mingw32-strip... (cached) i686-pc-mingw32-strip
checking for i686-pc-mingw32-ranlib... i686-pc-mingw32-ranlib
checking command to parse /usr/bin/i686-pc-mingw32-nm -B output from
i686-pc-mingw32-gcc object... ok
checking how to run the C preprocessor... i686-pc-mingw32-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if i686-pc-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for i686-pc-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if i686-pc-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if i686-pc-mingw32-gcc static flag -static works... yes
checking if i686-pc-mingw32-gcc supports -c -o file.o... yes
checking if i686-pc-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the i686-pc-mingw32-gcc linker
(/usr/i686-pc-mingw32/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether gcc understands -Wp,-D_FORTIFY_SOURCE=2... yes
checking whether gcc understands -fexceptions... yes
checking whether gcc understands -fstack-protector... yes
checking whether gcc understands --param=ssp-buffer-size=4... yes
checking whether gcc understands -fasynchronous-unwind-tables... yes
checking whether gcc understands -Wall... yes
checking whether gcc understands -Wmissing-prototypes... yes
checking whether gcc understands -std=c99... yes
checking whether gcc understands -Wnested-externs... yes
checking whether gcc understands -Wpointer-arith... yes
checking whether gcc understands -Wextra... yes
checking whether gcc understands -Wshadow... yes
checking whether gcc understands -Wcast-align... yes
checking whether gcc understands -Wwrite-strings... yes
checking whether gcc understands -Waggregate-return... yes
checking whether gcc understands -Winline... yes
checking whether gcc understands -Wredundant-decls... yes
checking whether gcc understands -Wno-sign-compare... yes
checking what language compliance flags to pass to the C compiler...
checking for i686-pc-mingw32-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
configure: WARNING: using cross tools not prefixed with host triplet
checking pkg-config is at least version 0.9.0... yes
checking for LIBXML2... yes
checking for LIBVIRT... yes
checking for GTK2... yes
checking for LIBGLADE2... yes
checking for GTKVNC... yes
checking sys/socket.h usability... no
checking sys/socket.h presence... no
checking for sys/socket.h... no
checking sys/un.h usability... no
checking sys/un.h presence... no
checking for sys/un.h... no
checking windows.h usability... yes
checking windows.h presence... yes
checking for windows.h... yes
checking for fork... no
checking for socketpair... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating man/Makefile
config.status: creating plugin/Makefile
config.status: creating virt-viewer.spec
config.status: creating mingw32-virt-viewer.spec
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
> What he hasn't asked, yet, is how porting libvirt and the virt-* utilis
> helps you.
>
> What is the actual end goal here? A "just for fun" experiment, in which
> case you are probably better served by answers to your questions which lead
> you to do the deeper debugging. Or a school project, in which case the same
> applies.
>
> Thanks,
> Anand

I had to call the libvirt functions from my windows machine and this could
only be done by porting libvirt to windows(as a client).. i have done that
sucessfully and now I can call all the functions from my windows machine...

Now what happens is that after I create a new Guest OS using my code(from
windows), I have to logon into my server machine and then continue
installing the Guest. This is where i thought of porting virt-viewer to
windows so that i can do it from the same remote windows machine.

The only problem that im facing right now is with the virt-viewer. If this
issues is resolved, we are thinking of intergate libvirt with one of our
product.

Regards
Anuj

[anuj rampal]

Hi,

I think there is some problem the windows port of virt-viewer or i guess i
have done something wrong.

I have made the Guest OS display on my Windows Machine but its not through
virt-viewer it just by using vnc.

As i was able to connect from a remote linux machine using virt-viewer. I
figured out that it connects to the libvirtd first and the connects to the
display port of the Guest OS.

Now when i was trying to connect from my windows machine, what was happening
was it was connecting to libvirtd and the hungs up and doesnot connect to
the display port of the Guest OS.

So i tried to directly connect to the display port of that Guest OS from my
Windows machine and i was able to see my Guest OS.

I dont know why virt-viewer is not working properly because internally it
also uses GTK-VNC only...????

Thanks & Regards
Anuj

On Tue, Oct 6, 2009 at 12:02 PM, anuj rampal  wrote:
> On Tue, Oct 6, 2009 at 5:01 AM, Anand Kumria wrote:
> > Hi,
> >
> > What's with the colours? Why are you making it harder to understand what
> > was said by who?
> > It would also be really useful if you kept the attribution lines, so we
> > could all see who had said what, when.
> >
> > What Richard is asking you for is the output of the ./configure command.
>
> These are the packages that are required: as given in the mingw32.spec
> file
> mingw32-filesystem
> mingw32-gtk2
> mingw32-libvirt
> mingw32-libxml2
> mingw32-libglade2
> mingw32-gtk-vnc
> pkgconfig
>
> These are all there..
>
> [root@FC11-KVM ~]# rpm -qa | grep mingw32-filesystem
> mingw32-filesystem-50-3.fc11.1.noarch
> [root@FC11-KVM ~]# rpm -qa | grep mingw32-gtk2
> mingw32-gtk2-2.16.6-1.fc11.noarch
> mingw32-gtk2-static-2.16.6-1.fc11.noarch
> [root@FC11-KVM ~]# rpm -qa | grep mingw32-libvirt
> mingw32-libvirt-0.6.1-1.fc11.noarch
> [root@FC11-KVM ~]# rpm -qa | grep mingw32-libxml2
> mingw32-libxml2-2.7.4-1.fc11.noarch
> mingw32-libxml2-static-2.7.4-1.fc11.noarch
> [root@FC11-KVM ~]# rpm -qa | grep mingw32-libglade2
> mingw32-libglade2-2.6.4-2.fc11.noarch
> mingw32-libglade2-static-2.6.4-2.fc11.noarch
> [root@FC11-KVM ~]# rpm -qa | grep mingw32-gtk-vnc
> mingw32-gtk-vnc-0.3.8-5.fc11.noarch
> [root@FC11-KVM ~]# rpm -qa | grep pkgconfig
> pkgconfig-0.23-8.fc11.i586
>
> this is how i configured the virt-viewer:
>
> PKG_CONFIG_PATH="/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig"
> CC="i686-pc-mingw32-gcc"  ./configure    --build=i386-pc-linux
> --host=i686-pc-mingw32    --prefix="/usr/i686-pc-mingw32/sys-root/mingw"
> --sysconfdir=C:\pki
>
> and here is the result:
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for i686-pc-mingw32-strip... i686-pc-mingw32-strip
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking build system type... i386-pc-linux-gnu
> checking host system type... i686-pc-mingw32
> checking for i686-pc-mingw32-gcc... i686-pc-mingw32-gcc
> checking for C compiler default output file name... a.exe
> checking whether the C compiler works... yes
> checking whether we are cross compiling... yes
> checking for suffix of executables... .exe
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether i686-pc-mingw32-gcc accepts -g... yes
> checking for i686-pc-mingw32-gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of i686-pc-mingw32-gcc... gcc3
> checking whether i686-pc-mingw32-gcc and cc understand -c and -o
> together... yes
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for ld used by i686-pc-mingw32-gcc... /usr/i686-pc-mingw32/bin/ld
> checking if the linker (/usr/i686-pc-mingw32/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)...
> /usr/bin/i686-pc-mingw32-nm -B
> checking the name lister (/usr/bin/i686-pc-mingw32-nm -B) interface... BSD
> nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 1966080
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for /usr/i686-pc-mingw32/bin/ld option to reload object files...
> -r
> checking for i686-pc-mingw32-objdump... i686-pc-mingw32-objdump
> checking how to recognize dependent libraries... file_magic ^x86 archive
> import|^x86 DLL
> checking for i686-pc-mingw32-ar... i686-pc-mingw32-ar
> checking for i686-pc-mingw32-strip... (cached) i686-pc-mingw32-strip
> checking for i686-pc-mingw32-ranlib... i686-pc-mingw32-ranlib
> checking command to parse /usr/bin/i686-pc-mingw32-nm -B output from
> i686-pc-mingw32-gcc object... ok
> checking how to run the C preprocessor... i686-pc-mingw32-gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if i686-pc-mingw32-gcc supports -fno-rtti -fno-exceptions... no
> checking for i686-pc-mingw32-gcc option to produce PIC... -DDLL_EXPORT
> -DPIC
> checking if i686-pc-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
> checking if i686-pc-mingw32-gcc static flag -static works... yes
> checking if i686-pc-mingw32-gcc supports -c -o file.o... yes
> checking if i686-pc-mingw32-gcc supports -c -o file.o... (cached) yes
> checking whether the i686-pc-mingw32-gcc linker
> (/usr/i686-pc-mingw32/bin/ld) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... yes
> checking dynamic linker characteristics... Win32 ld.exe
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking whether gcc understands -Wp,-D_FORTIFY_SOURCE=2... yes
> checking whether gcc understands -fexceptions... yes
> checking whether gcc understands -fstack-protector... yes
> checking whether gcc understands --param=ssp-buffer-size=4... yes
> checking whether gcc understands -fasynchronous-unwind-tables... yes
> checking whether gcc understands -Wall... yes
> checking whether gcc understands -Wmissing-prototypes... yes
> checking whether gcc understands -std=c99... yes
> checking whether gcc understands -Wnested-externs... yes
> checking whether gcc understands -Wpointer-arith... yes
> checking whether gcc understands -Wextra... yes
> checking whether gcc understands -Wshadow... yes
> checking whether gcc understands -Wcast-align... yes
> checking whether gcc understands -Wwrite-strings... yes
> checking whether gcc understands -Waggregate-return... yes
> checking whether gcc understands -Winline... yes
> checking whether gcc understands -Wredundant-decls... yes
> checking whether gcc understands -Wno-sign-compare... yes
> checking what language compliance flags to pass to the C compiler...
> checking for i686-pc-mingw32-pkg-config... no
> checking for pkg-config... /usr/bin/pkg-config
> configure: WARNING: using cross tools not prefixed with host triplet
> checking pkg-config is at least version 0.9.0... yes
> checking for LIBXML2... yes
> checking for LIBVIRT... yes
> checking for GTK2... yes
> checking for LIBGLADE2... yes
> checking for GTKVNC... yes
> checking sys/socket.h usability... no
> checking sys/socket.h presence... no
> checking for sys/socket.h... no
> checking sys/un.h usability... no
> checking sys/un.h presence... no
> checking for sys/un.h... no
> checking windows.h usability... yes
> checking windows.h presence... yes
> checking for windows.h... yes
> checking for fork... no
> checking for socketpair... no
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating src/Makefile
> config.status: creating man/Makefile
> config.status: creating plugin/Makefile
> config.status: creating virt-viewer.spec
> config.status: creating mingw32-virt-viewer.spec
> config.status: creating config.h
> config.status: executing depfiles commands
> config.status: executing libtool commands
> > What he hasn't asked, yet, is how porting libvirt and the virt-* utilis
> > helps you.
> >
> > What is the actual end goal here? A "just for fun" experiment, in which
> > case you are probably better served by answers to your questions which lead
> > you to do the deeper debugging. Or a school project, in which case the same
> > applies.
> >
> > Thanks,
> > Anand
>
> I had to call the libvirt functions from my windows machine and this could
> only be done by porting libvirt to windows(as a client).. i have done that
> sucessfully and now I can call all the functions from my windows machine...
>
> Now what happens is that after I create a new Guest OS using my code(from
> windows), I have to logon into my server machine and then continue
> installing the Guest. This is where i thought of porting virt-viewer to
> windows so that i can do it from the same remote windows machine.
>
> The only problem that im facing right now is with the virt-viewer. If this
> issues is resolved, we are thinking of intergate libvirt with one of our
> product.
>
> Regards
> Anuj