?Nice :) I will test this as soon as possible Arnaud -------------------------------------------------- From: "Justin Clift" <jclift(a)redhat.com&gt; Sent: Sunday, December 12, 2010 9:46 AM To: "Matthias Bolte" <matthias.bolte(a)googlemail.com&gt; Cc: "libvir-list libvirt" <libvir-list(a)redhat.com&gt; Subject: [libvirt] Got time to try out the libvirt 0.8.6 win32 package? > Hi Matthias (and anyone else interested), > > Just added a win32 installation package to the website, for libvirt > 0.8.6. > > http://libvirt.org/sources/win32_experimental/Libvirt-0.8.6-0.exe > > This has the libcurl stuff in it you put together, so (in theory) it > should > connect to remote vSphere/ESX servers. > > Do you (or anyone) have time to try it out against vSphere/ESX/similar? > > Going to update the Windows page on the website pointing to it, when > we know it's working ok. :) > > Regards and best wishes, > > Justin Clift > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 12/12/2010, at 9:50 PM, <arnaud.champion(a)devatom.fr&gt; <arnaud.champion(a)devatom.fr&gt; wrote: > ?Okay, I have tested it. > > At first, this works fine. No install problem, I have installed every > thing (python bindings, virsh and dev components). > > I have tested virsh with tcp+qemu and esx URI, both works fine. > I have also tested with C# libvirt bindings without surprise. Thanks Arnaud, those are the important bits at this stage. :) > Maybe a suggestion (don't know if it is pertinent or not) : when I have > tried C# bindings, I must copy libvirt binaries dll in the C# bindings > directory, so maybe it can be a good idea to add the install path of the > /bin dll directory to the PATH environment variable, in this way, no more > need to copy dlls. Sounds like a good idea. I'm not sure how to do that with NSIS (yet), but it should be possible. At the moment, I'm thinking that since the installer "works", to use this one as it is. But, we'll update the Windows page to mention it needs to be added to the path. When I (or anyone willing) gets a chance to fix the installer, so it updates the path, then we'll can generate a new installer and use that. Do you have any desire to create the Windows packages? Kind of thinking that you already know how to create .msi's... :) Regards and best wishes, Justin Clift

On 13/12/2010, at 5:02 AM, <arnaud.champion(a)devatom.fr&gt; <arnaud.champion(a)devatom.fr&gt; wrote: > ?I'm use to create msi packages with visual studio, I've never tried NSIS but I think I can help. I'm a little bit busy these times but I will give it a try. Thanks Arnaud. Using NSIS is not a requirement. I just used NSIS as a starting point, as I've used it before years ago. I suppose what we need is: a) Something that created windows packages :) b) Has a configuration, or script, or similar, that can be shared online. NSIS uses a text file. This gives the details of the package, and how the installer works. Does Visual Studio offer something similar? Maybe output for the Microsoft WiX toolset? There might be other things, but they're the main points I can think of at the moment.

On 12/12/2010, at 9:50 PM, <arnaud.champion(a)devatom.fr&gt; <arnaud.champion(a)devatom.fr&gt; wrote: > Maybe a suggestion (don't know if it is pertinent or not) : when I have > tried C# bindings, I must copy libvirt binaries dll in the C# bindings > directory, so maybe it can be a good idea to add the install path of the > /bin dll directory to the PATH environment variable, in this way, no more > need to copy dlls. With this specific problem, do you know if "registering" the dll's be the right approach? Something like: regsvr32.exe /s iconv.dll regsvr32.exe /s intl.dll regsvr32.exe /s libcurl-4.dll regsvr32.exe /s libgcrypt-11.dll regsvr32.exe /s libgnutls-26.dll regsvr32.exe /s libgpg-error-0.dll regsvr32.exe /s libportablexdr-0.dll regsvr32.exe /s libtasn1-3.dll regsvr32.exe /s libvirt-0.dll regsvr32.exe /s libvirt-qemu-0.dll regsvr32.exe /s libxml2-2.dll regsvr32.exe /s zlib1.dll (probably with the path names though) I'm kind of thinking it's the right idea, but am concerned about conflict other applications that might be using the same libraries (zlib1.dll for example). Any ideas? Regards and best wishes, Justin Clift

That's correct, regsvr32 is for registering COM components. It has nothing to do with the runtime linker finding the DLLs. In order to have libvirt-0.dll available for applications it must either be in the same directory as the application's binary (having it in the working directory might work too), or it must be in the PATH. But putting \bin in the PATH pollutes the global DLL namespace with common DLLs like zlib1.dll. This makes DLL hell worse. Strawberry Perl avoids this by making the DLL name unique to Strawberry Perl by posfixing them with an underscore. I just hacked a small C program that can rewrite the DLL import tables. This allows to easily prefix all DLLs in \bin (expect libvirt-0.dll and libvirt-qemu-0.dll) without touching all the buildsystems for those DLLs to rename them. Instead of this filenames in \bin: iconv.dll intl.dll libcurl-4.dll libgcrypt-11.dll libgnutls-26.dll libgpg-error-0.dll libportablexdr-0.dll libtasn1-3.dll libvirt-0.dll libvirt-qemu-0.dll libxml2-2.dll virsh.exe zlib1.dll we can have this ones: libvirt-0.dll libvirt-qemu-0.dll virsh.exe _lv_iconv.dll _lv_intl.dll _lv_libcurl-4.dll _lv_libgcrypt-11.dll _lv_libgnutls-26.dll _lv_libgpg-error-0.dll _lv_libportablexdr-0.dll _lv_libtasn1-3.dll _lv_libxml2-2.dll _lv_zlib1.dll Or with any other prefix/postfix with up to 4 characters. Matthias 2010/12/20 <arnaud.champion(a)devatom.fr&gt;: > ?Hi Justin, > > I don't think regsvr32 will work, as I know, regsvr32 is used to register > COM components against registry, and these dlls are not COM compatible. > > Arnaud > > -------------------------------------------------- > From: "Justin Clift" <jclift(a)redhat.com&gt; > Sent: Monday, December 20, 2010 6:27 AM > To: "Arnaud Champion" <arnaud.champion(a)devatom.fr&gt; > Cc: "libvir-list libvirt" <libvir-list(a)redhat.com&gt; > Subject: Re: [libvirt] Got time to try out the libvirt 0.8.6 win32 > package? > >> On 12/12/2010, at 9:50 PM, <arnaud.champion(a)devatom.fr&gt; >> <arnaud.champion(a)devatom.fr&gt; wrote: >>> >>> Maybe a suggestion (don't know if it is pertinent or not) : when I have >>> tried C# bindings, I must copy libvirt binaries dll in the C# bindings >>> directory, so maybe it can be a good idea to add the install path of >>> the >>> /bin dll directory to the PATH environment variable, in this way, no >>> more >>> need to copy dlls. >> >> With this specific problem, do you know if "registering" the dll's be >> the >> right approach? >> >> Something like: >> >> regsvr32.exe /s iconv.dll >> regsvr32.exe /s intl.dll >> regsvr32.exe /s libcurl-4.dll >> regsvr32.exe /s libgcrypt-11.dll >> regsvr32.exe /s libgnutls-26.dll >> regsvr32.exe /s libgpg-error-0.dll >> regsvr32.exe /s libportablexdr-0.dll >> regsvr32.exe /s libtasn1-3.dll >> regsvr32.exe /s libvirt-0.dll >> regsvr32.exe /s libvirt-qemu-0.dll >> regsvr32.exe /s libxml2-2.dll >> regsvr32.exe /s zlib1.dll >> >> (probably with the path names though) >> >> I'm kind of thinking it's the right idea, but am concerned about >> conflict >> other applications that might >> be using the same libraries (zlib1.dll for example). >> >> Any ideas? >> >> Regards and best wishes, >> >> Justin Clift > > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >

Hi Matthias (and anyone else interested), Just added a win32 installation package to the website, for libvirt 0.8.6.  http://libvirt.org/sources/win32_experimental/Libvirt-0.8.6-0.exe This has the libcurl stuff in it you put together, so (in theory) it should connect to remote vSphere/ESX servers. Do you (or anyone) have time to try it out against vSphere/ESX/similar? Going to update the Windows page on the website pointing to it, when we know it's working ok. :) Regards and best wishes, Justin Clift

2010/12/12 Justin Clift <jclift(a)redhat.com&gt;: > Hi Matthias (and anyone else interested), > > Just added a win32 installation package to the website, for libvirt 0.8.6. > >  http://libvirt.org/sources/win32_experimental/Libvirt-0.8.6-0.exe > > This has the libcurl stuff in it you put together, so (in theory) it should > connect to remote vSphere/ESX servers. > > Do you (or anyone) have time to try it out against vSphere/ESX/similar? > > Going to update the Windows page on the website pointing to it, when > we know it's working ok. :) > > Regards and best wishes, > > Justin Clift > I tested it and it works with ESX and QEMU over TLS. Here are some comments: 1) I wonder why you never pushed this patch: https://www.redhat.com/archives/libvir-list/2010-November/msg00761.html 2) libcurl license is missing in the installer. 3) There is no readme.txt about where to put TLS certs to make qemu+tls:// work. 4) The installer remembers the install location. Therefore, it suggest to install in the same location as the previous installer for libvirt 0.8.5. But it doesn't check if a previous version is already installed and doesn't suggest to uninstall it first. This results in libvirt 0.8.6 being installed over 0.8.5. The installer overwrites existing files without notice.

On 14/12/2010, at 3:38 AM, Daniel P. Berrange wrote: > This raises the question of how the tools depending on libvirt > will be distributed. eg virt-viewer.  If they're separate, then > we need to make sure the tools continue working, after any update > of libvirt without changing paths manually. > > IMHO, rather than just distributing a libvirt installer, we should > distribute a 'virt tools' installer on virt-tools.org which has > a complete bundle of everything that has been ported to Win32, > libvirt core, language bindings and apps. The installer would of > course allow you to pick & choose which bits to install. Yeah, that's not a bad idea too. One of the interesting things that turned up from this exercise so far, is that having a shortcut to virsh.exe in the windows install menu doesn't work (tried it).  Virsh (on windows) needs to be given a connection string in order to do anything.  Without it, it just displays an error message then exits.

Using a shortcut at the moment means the user sees a black dos prompt screen show up for a fraction of a second (not long enough to read the text) then disappear.  Not real practical, so disabled the shortcut creation. Thinking what we'd probably want to do for virsh is have a dialog or something that lets the user assemble a connection string, then launches virsh using that.  Someone probably has a better idea than that though. :)

This really wants a trivial GTK app around it. Just popup a dialog box, that populates a list of auto-detected URLs from avahi (or Win32 equivalent), or a text field to enter one manually. Then just launch virsh with whatever they choose.