[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
?Nice :) I will test this as soon as possible Arnaud -------------------------------------------------- From: "Justin Clift" <jclift@redhat.com> Sent: Sunday, December 12, 2010 9:46 AM To: "Matthias Bolte" <matthias.bolte@googlemail.com> Cc: "libvir-list libvirt" <libvir-list@redhat.com> 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
?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. 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. Arnaud -------------------------------------------------- From: <arnaud.champion@devatom.fr> Sent: Sunday, December 12, 2010 11:25 AM To: "Justin Clift" <jclift@redhat.com>; "Matthias Bolte" <matthias.bolte@googlemail.com> Cc: "libvir-list libvirt" <libvir-list@redhat.com> Subject: Re: [libvirt] Got time to try out the libvirt 0.8.6 win32 package?
?Nice :)
I will test this as soon as possible
Arnaud
-------------------------------------------------- From: "Justin Clift" <jclift@redhat.com> Sent: Sunday, December 12, 2010 9:46 AM To: "Matthias Bolte" <matthias.bolte@googlemail.com> Cc: "libvir-list libvirt" <libvir-list@redhat.com> 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 12/12/2010, at 9:50 PM, <arnaud.champion@devatom.fr> <arnaud.champion@devatom.fr> 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
?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. Arnaud -------------------------------------------------- From: "Justin Clift" <jclift@redhat.com> Sent: Sunday, December 12, 2010 6:13 PM To: "Arnaud Champion" <arnaud.champion@devatom.fr> Cc: "Matthias Bolte" <matthias.bolte@googlemail.com>; "libvir-list libvirt" <libvir-list@redhat.com> 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@devatom.fr> <arnaud.champion@devatom.fr> 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@devatom.fr> <arnaud.champion@devatom.fr> 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. :) Regards and best wishes, Justin Clift
Arnaud
On Mon, Dec 13, 2010 at 02:23:26PM +1100, Justin Clift wrote:
On 13/12/2010, at 5:02 AM, <arnaud.champion@devatom.fr> <arnaud.champion@devatom.fr> 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.
Anything we use to build installers that we distribute on libvirt.org must be using a 100% open source tool chain. This rules out any use of Visual Studio, etc. There is, however, an open source WiX toolset on sourceforge IIRC. Regards, Daniel
On 12/12/2010, at 9:50 PM, <arnaud.champion@devatom.fr> <arnaud.champion@devatom.fr> 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
?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@redhat.com> Sent: Monday, December 20, 2010 6:27 AM To: "Arnaud Champion" <arnaud.champion@devatom.fr> Cc: "libvir-list libvirt" <libvir-list@redhat.com> 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@devatom.fr> <arnaud.champion@devatom.fr> 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@devatom.fr>:
?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@redhat.com> Sent: Monday, December 20, 2010 6:27 AM To: "Arnaud Champion" <arnaud.champion@devatom.fr> Cc: "libvir-list libvirt" <libvir-list@redhat.com> 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@devatom.fr> <arnaud.champion@devatom.fr> 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
good idea. What about a prefix like "vir_" ? -------------------------------------------------- From: "Matthias Bolte" <matthias.bolte@googlemail.com> Sent: Monday, December 20, 2010 4:03 PM To: <arnaud.champion@devatom.fr> Cc: "Justin Clift" <jclift@redhat.com>; "libvir-list libvirt" <libvir-list@redhat.com> Subject: Re: [libvirt] Got time to try out the libvirt 0.8.6 win32 package?
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@devatom.fr>:
?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@redhat.com> Sent: Monday, December 20, 2010 6:27 AM To: "Arnaud Champion" <arnaud.champion@devatom.fr> Cc: "libvir-list libvirt" <libvir-list@redhat.com> 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@devatom.fr> <arnaud.champion@devatom.fr> 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 21/12/2010, at 2:03 AM, Matthias Bolte wrote:
That's correct, regsvr32 is for registering COM components. It has nothing to do with the runtime linker finding the DLLs. <snip> Or with any other prefix/postfix with up to 4 characters.
Works for me. Personally, totally not bothered what the prefix is, so "you guys decide". I'll just package whatever the msys_setup output is (assuming the util is included in that). :)
2010/12/12 Justin Clift <jclift@redhat.com>:
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. Matthias
On 14/12/2010, at 12:29 AM, Matthias Bolte wrote:
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
Heh, because it never got ACK'd. :) Was mostly waiting for the TLS stuff to work well enough to be practical, which I reckon your recent patches for %APPDATA% location should have done. So, going to make a v2 of that patch, mentioning ESX support and location of the TLS certificates.
2) libcurl license is missing in the installer.
Ugh, you're right. Even after doing the work to locate and copy it into the installer source tree, missed getting it into the package itself. :/ That's now fixed, and I've just pushed a new version of the 0.8.6 installer (using exact same name) to the libvirt site.
3) There is no readme.txt about where to put TLS certs to make qemu+tls:// work.
Yeah, was thinking that should go on the Windows page. But, now you mention it, having a readme or similar installed with the package itself is probably a good idea. I'll create a new version of the installer, including it.
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.
Ouch, good point. Now sure how to work around this atm, though in theory it should be a matter of doing what you mention... detect installation already in existence, offer to uninstall. Also refusing to install over the same location as an existing installer in case the user doesn't want to install. For now, probably worth putting a note of the problem on the to-be-done Windows page, and mentioning it in the to-be-done readme file. But, it really needs to be fixed in a subsequent release. :)
On Mon, Dec 13, 2010 at 02:29:43PM +0100, Matthias Bolte wrote:
2010/12/12 Justin Clift <jclift@redhat.com>:
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.
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. Regards, Daniel
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. :)
2010/12/13 Justin Clift <jclift@redhat.com>:
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.
That's because autodetection for the URI doesn't work with remote drivers only. You cannot guess the server name.
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. :)
Well, you can do that with a simple batch file: @echo off set /p uri="Enter libvirt connection URI: " virsh.exe -c %uri% pause Put that in a virsh-launcher.bat in the same directory as virsh.exe and link to it. The set /p command outputs the prompt string and lets the user input a line of text and assigns it to the uri variable. The pause at the end stops the command window from closing automatically when virsh exits. You might add some informative output before the set /p using echo. Matthias
On Mon, Dec 13, 2010 at 06:32:43PM +0100, Matthias Bolte wrote:
2010/12/13 Justin Clift <jclift@redhat.com>:
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.
That's because autodetection for the URI doesn't work with remote drivers only. You cannot guess the server name.
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. :)
Well, you can do that with a simple batch file:
@echo off set /p uri="Enter libvirt connection URI: " virsh.exe -c %uri% pause
Put that in a virsh-launcher.bat in the same directory as virsh.exe and link to it.
The set /p command outputs the prompt string and lets the user input a line of text and assigns it to the uri variable. The pause at the end stops the command window from closing automatically when virsh exits.
You might add some informative output before the set /p using echo.
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. Regards, Daniel
On 14/12/2010, at 10:07 PM, Daniel P. Berrange wrote:
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.
It'd be useful to keep the history of connection strings too, in a drop down list or something, for subsequent selection.
On 14/12/2010, at 4:32 AM, Matthias Bolte wrote:
Well, you can do that with a simple batch file:
@echo off set /p uri="Enter libvirt connection URI: " virsh.exe -c %uri% pause
Just uploaded a tweaked version of the installer, using this simple batch file approach, and also including a README (with shortcuts) as you suggested: http://libvirt.org/sources/win32_experimental/Libvirt-0.8.6-1.exe I should be able to get the patch for the Windows page updated and submitted today too. Regards and best wishes, Justin Clift
participants (4)
-
arnaud.champion＠devatom.fr -
Daniel P. Berrange -
Justin Clift -
Matthias Bolte