[Libvir] [PATCH] Compile libvirt under Windows (Cygwin)
The following patchset allows an incomplete compilation of libvirt under Windows using Cygwin. Current limitations are: (1) Xen driver does not work. This is not an important limitation because Windows cannot act as dom0 in a Xen hypervisor anyway (or if it can, it's not a very common configuration). (2) QEMU driver / libvirtd cannot be compiled. It's probably not too hard to fix this. The major area of concern is networking, in particular the very Linux-specific code in src/bridge.c. (2b) I have assumed for the purposes of (2) above that ./configure --without-qemu also disables libvirtd (server) support. QEMU and libvirtd are too entangled at the moment. (3) Cygwin is required. In other words, there is no true native compilation using VC++ or anything like that. However you still get *.exe files, so maybe this isn't an important limitation. Attached is a screenshot showing virsh being used to list QEMU instances over a TLS-encrypted remote connection. To compile this yourself: (a) Set up a Windows machine with plenty of free disk space (10GB+). (b) Install Cygwin (http://www.cygwin.com/). Cygwin has an obscure, unusable packaging system. The trick is to click the "recycling symbol" next to "All". This will download and install everything. You may if you prefer install just the packages you need, but the list of dependencies is long and currently undocumented. (c) Check out libvirt from CVS, apply these patches. (d) rm qemud/remote_protocol.[ch] qemud/remote_dispatch_*.h (e) ./configure --without-xen --without-qemu (f) make -C qemud remote_protocol.c (g) make (h) make install Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Libvirt can be compiled against gnutls 1.0 (in fact we carry compatibility checks and a header file for this very reason). Cygwin only has gnutls 1.0.25, so make that the minimum instead of 1.2.0. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:24:53PM +0000, Richard W.M. Jones wrote:
Libvirt can be compiled against gnutls 1.0 (in fact we carry compatibility checks and a header file for this very reason). Cygwin only has gnutls 1.0.25, so make that the minimum instead of 1.2.0.
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
'cfmakeraw' is a BSD function. If we don't have it, inline the equivalent code instead. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:25:54PM +0000, Richard W.M. Jones wrote:
'cfmakeraw' is a BSD function. If we don't have it, inline the equivalent code instead.
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
"Richard W.M. Jones" <rjones@redhat.com> wrote:
'cfmakeraw' is a BSD function. If we don't have it, inline the equivalent code instead. ... Index: src/console.c +#ifdef HAVE_CFMAKERAW cfmakeraw(&rawattr); +#else + rawattr.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP + | INLCR | IGNCR | ICRNL | IXON); + rawattr.c_oflag &= ~OPOST; + rawattr.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); + rawattr.c_cflag &= ~(CSIZE | PARENB); + rawattr.c_cflag |= CS8; +#endif
if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &rawattr) < 0) { fprintf(stderr, _("unable to set tty attributes: %s\n"),
Hi Rich, I like to avoid in-function #ifdefs. To that end, what do you think about a function like this: #ifdef HAVE_CFMAKERAW static void cfmakeraw (whatever) { rawattr.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); rawattr.c_oflag &= ~OPOST; rawattr.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); rawattr.c_cflag &= ~(CSIZE | PARENB); rawattr.c_cflag |= CS8; } #ifdef HAVE_CFMAKERAW Then you don't have to change the code that *uses* cfmakeraw.
Jim Meyering <jim@meyering.net> wrote:
"Richard W.M. Jones" <rjones@redhat.com> wrote:
'cfmakeraw' is a BSD function. If we don't have it, inline the equivalent code instead. ... Index: src/console.c +#ifdef HAVE_CFMAKERAW cfmakeraw(&rawattr); +#else + rawattr.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP + | INLCR | IGNCR | ICRNL | IXON); + rawattr.c_oflag &= ~OPOST; + rawattr.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); + rawattr.c_cflag &= ~(CSIZE | PARENB); + rawattr.c_cflag |= CS8; +#endif
if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &rawattr) < 0) { fprintf(stderr, _("unable to set tty attributes: %s\n"),
Hi Rich,
I like to avoid in-function #ifdefs. To that end, what do you think about a function like this:
#ifdef HAVE_CFMAKERAW static void cfmakeraw (whatever) { rawattr.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); rawattr.c_oflag &= ~OPOST; rawattr.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); rawattr.c_cflag &= ~(CSIZE | PARENB); rawattr.c_cflag |= CS8;
Of course, it'd have to be ->, not "."
PATH_MAX requires <sys/syslimits.h> on Cygwin. HOST_NAME_MAX and IF_NAMESIZE aren't present at all on Cygwin, so if they are not defined hard code defaults for them. There shouldn't be a problem because we should still use functions which work if the actual values are longer than these default sizes. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:27:47PM +0000, Richard W.M. Jones wrote:
PATH_MAX requires <sys/syslimits.h> on Cygwin.
HOST_NAME_MAX and IF_NAMESIZE aren't present at all on Cygwin, so if they are not defined hard code defaults for them. There shouldn't be a problem because we should still use functions which work if the actual values are longer than these default sizes.
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
'getaddrinfo' isn't available under Cygwin. This patch adds a general feature detection for getaddrinfo and getnameinfo and if they are not present replaces them with equivalents which we ship. The replacements come from this BSD-licensed implementation by Motoyuki Kasahara: http://www.sra.co.jp/people/m-kasahr/getaddrinfo/ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:29:45PM +0000, Richard W.M. Jones wrote:
'getaddrinfo' isn't available under Cygwin. This patch adds a general feature detection for getaddrinfo and getnameinfo and if they are not present replaces them with equivalents which we ship.
The replacements come from this BSD-licensed implementation by Motoyuki Kasahara:
ACK all the getaddrinfo stuff, except what is this bit for ?
-libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) +libvirt_la_LIBADD = $(LIBXML_LIBS) $(GNUTLS_LIBS) $(LTLIBOBJS)
Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
"Richard W.M. Jones" <rjones@redhat.com> wrote:
'getaddrinfo' isn't available under Cygwin. This patch adds a general feature detection for getaddrinfo and getnameinfo and if they are not present replaces them with equivalents which we ship.
The replacements come from this BSD-licensed implementation by Motoyuki Kasahara:
Hi Rich, Do you happen to know how that implementation compares to what's in gnulib? http://www.gnu.org/software/gnulib/MODULES.html#module=getaddrinfo One thing I noticed is that it lacks IPv6 support. Obviously, we don't care too much if a system needing the replacement can't do IPv6, but if we get it for free, it makes the rest of the code cleaner to be able to assume IPv6-related definitions are always available. Since coreutils, gnutls, and a few other well-known projects use the one in gnulib, if there's anything wrong with it, I'll make sure it gets fixed right away. One advantage of the above version is that it doesn't depend on the following modules from gnulib: extensions gettext-h inet_ntop snprintf socklen stdbool strdup sys_socket An argument in favor of the gnulib-based implementation is that with gnulib-tool, it encapsulates all of the autoconf and Makefile.am changes required to add everything automatically. Also, if you care about portability, you might as well do it "right" and ensure that the required functions like socklen, snprintf, and inet_ntop, are available and working. And if not, provide working replacements. Being able to depend on the fundamentals can make debugging a lot less frustrating. By the way, all of those gnulib modules are covered by LGPLv2+, so no problem with copyright. Eventually, I plan to do something like this anyhow, for portable memory-related info (i.e., gnulib's physmem module), so I've added this one to the list.
Detect if the XDR functions are in a separate library which needs `-lrpc' to link against (Cygwin for sure, probably Solaris too). Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:31:03PM +0000, Richard W.M. Jones wrote:
Detect if the XDR functions are in a separate library which needs `-lrpc' to link against (Cygwin for sure, probably Solaris too).
ACK Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Check if the rpcgen program is available. The rpcgen under Cygwin doesn't generate buggy code (unlike glibc's rpcgen) so there is no need to run the Perl fix-up script. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:32:29PM +0000, Richard W.M. Jones wrote:
Check if the rpcgen program is available.
The rpcgen under Cygwin doesn't generate buggy code (unlike glibc's rpcgen) so there is no need to run the Perl fix-up script.
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Miscellaneous pair of fixes for src/remote_internal.c. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:33:11PM +0000, Richard W.M. Jones wrote:
Miscellaneous pair of fixes for src/remote_internal.c.
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
This patch just disables all server and QEMU-related code if we configure --without-qemu. As discussed in the intro this should be made more granular so we can disable server or QEMU features alone. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 02:34:40PM +0000, Richard W.M. Jones wrote:
This patch just disables all server and QEMU-related code if we configure --without-qemu.
Unless I'm mistaken, this only seeems to disable QEMU related code. It doesn't seem to touch anything in the server qemud/* directory. Which is fine, of course - there shouldn't be any dependancy between the server & QEMU any more. It should be possible to have libvirtd without the QEMU driver present no problem. So, ACK to this.
As discussed in the intro this should be made more granular so we can disable server or QEMU features alone.
AFAIK, the main problem is the inter-twining of the QEMU and the network driverrs. That's the key bit we need to make independant, so you can have Xen only + networking stuff, but no QEMU. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Four more patches - these should be applied after the first 8 above, and fix libvirtd, proxy and tests. - - - The attached patch disables the Xen proxy, since (AFAICS) it can't possibly be used under Windows. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 05:16:39PM +0000, Richard W.M. Jones wrote:
Four more patches - these should be applied after the first 8 above, and fix libvirtd, proxy and tests.
- - -
The attached patch disables the Xen proxy, since (AFAICS) it can't possibly be used under Windows.
ACK. There's no need for the proxy, since there's no windows Dom0 Xen. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
This patch and the next one are required to fix libvirtd. Of course although libvirtd builds, it's not really very useful unless you want to run the test driver remotely :-) Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 05:18:03PM +0000, Richard W.M. Jones wrote:
This patch and the next one are required to fix libvirtd. Of course although libvirtd builds, it's not really very useful unless you want to run the test driver remotely :-)
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
AF_INET6 doesn't appear to be supported in Cygwin. Ho hum. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 05:18:44PM +0000, Richard W.M. Jones wrote:
AF_INET6 doesn't appear to be supported in Cygwin. Ho hum.
Wow. That's lame. Gues that explains why there's no getaddrinfo too, since its kinda pointless having getaddrinfo without IPv6 support. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Miscellaneous minor fixes for the tests/ subdirectory. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Sat, Nov 24, 2007 at 05:19:32PM +0000, Richard W.M. Jones wrote:
Miscellaneous minor fixes for the tests/ subdirectory.
ACK. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
"Richard W.M. Jones" <rjones@redhat.com> wrote:
Miscellaneous minor fixes for the tests/ subdirectory. Index: tests/qemuxml2argvtest.c =================================================================== RCS file: /data/cvs/libvirt/tests/qemuxml2argvtest.c,v retrieving revision 1.7 diff -u -r1.7 qemuxml2argvtest.c --- tests/qemuxml2argvtest.c 14 Nov 2007 10:35:59 -0000 1.7 +++ tests/qemuxml2argvtest.c 24 Nov 2007 17:07:16 -0000 ... +#else + +int main (void) { exit (EXIT_SUCCESS); }
When skipping an automake-run test, it's good to exit 77. That tells automake that the test was skipped, and then automake tells people who run 'make check'.
Index: tests/qemuxml2xmltest.c ... +int main (void) { exit (EXIT_SUCCESS); } + +#endif /* WITH_QEMU */
Jim Meyering wrote:
"Richard W.M. Jones" <rjones@redhat.com> wrote:
The following patchset allows an incomplete compilation of libvirt under Windows using Cygwin. Current limitations are:
Nice work! I admire your fortitude :-) This should help libvirt get more exposure.
Thanks for the encouragement! For the record I have now applied all the patches to CVS as posted, except where noted: (1) I reimplemented cfmakeraw as a separate function as per your suggestion. (2) Unimplemented tests changed to return 77 instead of EXIT_SUCCESS. (3) I left out the alternate getaddrinfo implementation until I have time to look at gnulib. I wasn't aware of this library actually. Unfortunately I can't easily check whether it works under Cygwin because my (working) Windows installation is not with me at the moment. Currently the main problem is persuading libtool to build Windows shared libraries (DLLs). I've followed all the instructions in the manual and various things from the web and it just doesn't work (as Dan said "Isn't libtool supposed to sort this out?"). Without having at least libvirtmod.dll, Python support is hard to do, which means of course that virt-manager doesn't work yet. Anyone who wants to try libvirt under Windows today, you will need libvirt from CVS + the attached patch to get it to build (but not yet to get shared libs working). Rich.
On Mon, Nov 26, 2007 at 12:44:49PM +0000, Richard Jones wrote:
Jim Meyering wrote:
"Richard W.M. Jones" <rjones@redhat.com> wrote:
The following patchset allows an incomplete compilation of libvirt under Windows using Cygwin. Current limitations are:
Nice work! I admire your fortitude :-) This should help libvirt get more exposure.
Thanks for the encouragement!
Well that's really cool. I assume what you get in the end is the library with just the remote support, but which should be sufficient to connect to the boxes hosting the hypervisors and libvirt daemon, right ?
For the record I have now applied all the patches to CVS as posted, [...] Currently the main problem is persuading libtool to build Windows shared libraries (DLLs). I've followed all the instructions in the manual and various things from the web and it just doesn't work (as Dan said "Isn't libtool supposed to sort this out?").
Hum, also one of the problem i found out quickly with libxml2 on windows is that most people just can use cygwin, some just fallback to mingw for licencing issues but a large majority use some kind of Microsoft compilers, and getting a DLL which works with more than one can be seriously challenging.
Without having at least libvirtmod.dll, Python support is hard to do, which means of course that virt-manager doesn't work yet.
If the goal is to get virt-manager working, then yes cygwin should be just fine once the shared lib issue is fixed. I assume virsh remote support works now, right ?
Anyone who wants to try libvirt under Windows today, you will need libvirt from CVS + the attached patch to get it to build (but not yet to get shared libs working). [...] Index: src/getaddrinfo.c =================================================================== RCS file: src/getaddrinfo.c diff -N src/getaddrinfo.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/getaddrinfo.c 26 Nov 2007 12:36:02 -0000 @@ -0,0 +1,593 @@ +/* + * Copyright (c) 2001, 02 Motoyuki Kasahara + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution.
Ouch, that's not really something we can embbed generally ... thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
Well that's really cool. I assume what you get in the end is the library with just the remote support, but which should be sufficient to connect to the boxes hosting the hypervisors and libvirt daemon, right ?
Yes, that's exactly right. It should be enough to run virt-manager and connect it to remote hosts. virt-manager needs some additional changes to work well in the remote case, but those changes are not Windows specific. Obviously Windows Xen support won't work unless Xen is somehow ported to Windows. However QEMU support is a possibility. The main difficulty with QEMU support would be the networking code.
For the record I have now applied all the patches to CVS as posted, [...] Currently the main problem is persuading libtool to build Windows shared libraries (DLLs). I've followed all the instructions in the manual and various things from the web and it just doesn't work (as Dan said "Isn't libtool supposed to sort this out?").
Hum, also one of the problem i found out quickly with libxml2 on windows is that most people just can use cygwin, some just fallback to mingw for licencing issues but a large majority use some kind of Microsoft compilers, and getting a DLL which works with more than one can be seriously challenging.
Yes, I punted on getting libvirt to work with VC++. From my past experience this would require very invasive changes to the code (eg. removing all gcc-isms, adding lots of Windows-isms). Cygwin still builds Windows native *.exe and *.dll (well, the latter _if_ I can get it working :-) AIUI all that is needed is to ship the Cygwin DLL (CYGWIN1.DLL) and the *.exe should work everywhere. I'm going to test this theory later.
Without having at least libvirtmod.dll, Python support is hard to do, which means of course that virt-manager doesn't work yet.
If the goal is to get virt-manager working, then yes cygwin should be just fine once the shared lib issue is fixed. I assume virsh remote support works now, right ?
Yes, see the screenshot in the first post in this thread.
Anyone who wants to try libvirt under Windows today, you will need libvirt from CVS + the attached patch to get it to build (but not yet to get shared libs working). [...] Index: src/getaddrinfo.c =================================================================== RCS file: src/getaddrinfo.c diff -N src/getaddrinfo.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/getaddrinfo.c 26 Nov 2007 12:36:02 -0000 @@ -0,0 +1,593 @@ +/* + * Copyright (c) 2001, 02 Motoyuki Kasahara + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution.
Ouch, that's not really something we can embbed generally ...
I'm going to look at an alternate implementation (in gnulib), but what is the problem with this license? Rich.
On Mon, Nov 26, 2007 at 03:10:43PM +0000, Richard Jones wrote: [...]
fine once the shared lib issue is fixed. I assume virsh remote support works now, right ?
Yes, see the screenshot in the first post in this thread.
dohh, missed it (for my defense my mail setup makes hard to show attached images :-)
+ * Copyright (c) 2001, 02 Motoyuki Kasahara + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution.
Ouch, that's not really something we can embbed generally ...
I'm going to look at an alternate implementation (in gnulib), but what is the problem with this license?
Well it asks for the copyright and those 3 conditions to be listed in all documentation (I think it's one of the BSD advertizing clause variants) and i really don't want to inflict this to people who build tools on top of libvirt. daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
Jim Meyering -
Richard Jones -
Richard W.M. Jones