FW: Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Hello libvirt-list,

We have a problem. It concerns CPU usage of libvirt library in Windows. It's not a problem in Linux. See attach.

At the moment we have a workaround for item 1 - we just calculate the number of handles which are leaked and restart our service if the number exceeds 10.000

As for item 2 - we have no real workaround. In 99.99% it should not happen, but there is still 0.01%
In libvirt.log you can find more info as suggested by Daniel.
================================================================
In the attached file, you will find detailed information regarding the case 100 percent CPU usage.
Our test was performed on the following system:
Windows XP SP3;
Libvirt-0.8.8;
Run the following command: virsh -c qemu+tcp: / /172.17.46.88:135/system
Port 135 was one of the ports on which our service is trying to connect.
================================================================

Could you help us here?

Thanks
Alexander

-----Original Message-----
From: Aliaksandr Chabatar 
Sent: Tuesday, March 15, 2011 3:52 PM
To: Ihar Smertsin
Subject: FW:  Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe

Hi Ihar,

Could you provide more information (log files, see below) so we could address this issue to libvir-list@xxxxxxxxxx ?

Mfg
Alexander

-----Original Message-----
From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] 
Sent: Tuesday, March 15, 2011 3:08 PM
To: Aliaksandr Chabatar
Cc: Hempfer, Siegfried; Boehme, Alfred; Schnizer, Monika
Subject: Re:  Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe

On Tue, Mar 15, 2011 at 04:01:31PM +0200, Aliaksandr Chabatar wrote:
> Dear Daniel,
> 
> I have another question. It concerns CPU usage of libvirt library
> in Windows. It's not a problem in Linux. See attach.
> 
> At the moment we have a workaround for item 1 - we just calculate
> the number of handles which are leaked and restart our service if
> the number exceeds 10.000

It sounds like we have some crazy resource leak in a piece of
code. I'm not too familiar with Windows, but if you re-send
this mail of yours to libvir-list@xxxxxxxxxx, I expect one of
the community members who knows Windows will be able to advise.

> As for item 2 - we have no real workaround. In 99.99% it should
> not happen, but there is still 0.01%

Yeah, that sounds like some piece of code is missing correct
error checking. It would be useful to try and obtain a couple
of stack traces when it is showing 100% cpu usage. Or capture
a libvirt debug log, eg by setting an environment variable
in your client application

  LIBVIRT_LOG_FILTERS="1:libvirt 1:util 1:remote"
  LIBVIRT_LOG_OUTPUTS="1:file:libvirt.log"

Again, sending this log + the info from your mail to the libvir-list
would be best.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--- Begin Message --- 
Dear Daniel,

I have another question. It concerns CPU usage of libvirt library in Windows. It's not a problem in Linux. See attach.

At the moment we have a workaround for item 1 - we just calculate the number of handles which are leaked and restart our service if the number exceeds 10.000

As for item 2 - we have no real workaround. In 99.99% it should not happen, but there is still 0.01%

Could you help us here?

Thanks
Alexander

--
Alexander Chabatar
Local Engineering Resident

FUJITSU
Fujitsu Technology Solutions GmbH
Domagkstraße 28, 80807 München, Deutschland
Tel:      +49 (89) 3222 3096
Mob:    +49 (173) 530 8737
Email: a.chabatar@xxxxxxxxxxxxxxxxx
ICQ: 561583724
Skype: alexander.chabatar
Web: ts.fujitsu.com
Company details: de.ts.fujitsu.com/imprint


-----Original Message-----
From: Schnizer, Monika [mailto:monika.schnizer@xxxxxxxxxxxxxx]
Sent: Thursday, February 24, 2011 5:46 PM
To: Aliaksandr Chabatar
Cc: Hempfer, Siegfried; Boehme, Alfred
Subject: FW:  Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe

 Hello Alexandr,

        using the installation executable, and extracting dlls, and repackage the dlls with our
SW is not possible.
At least that is the statement I received with regard to my questions posted in
libvirt mailing lists.
For details, please see below.

The alternative is described as well, building libvirt for Windows ourselves.

With best regards,
Monika



-----Original Message-----
From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx]
Sent: Thursday, February 24, 2011 5:40 PM
To: Schnizer, Monika
Cc: libvir-list@xxxxxxxxxx
Subject: Re:  Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe

On Thu, Feb 24, 2011 at 05:30:45PM +0100, Schnizer, Monika wrote:
> Dear Daniel,
>
>       thank you very much for your quick answer.
>
> Yes, I have read LGPL in detail.
> And to be honest, I have doubts that we can proceed in the way proposed.
> Some discussions cannot simply done with legal, as all LGPL does have
> aspects that are more technical. So in fact technical and legal
> knowledge do have to be combined.
>
> So let me outline, why I do have doubts that we can proceed in this way:
> a) If we use that installation executable, we need to have exactly those sources,
>    including the scripts that create the executable.

Yes, that is correct.

> b) As soon as we take only parts of the complete work, e.g. take
>    only some libraries out of it, then under strict interpretation
>    of the LGPL, we would create a work based on the orginal work.
>    The original work in this case being the installation executable,
>    all ist binaries and sources.
> c) Having a work based on the original code the LGPL is very strict:
>    We could only distribute it separately from our other SW, in order
>    to avoid a strong copy-left-effect.
>
> The question now is:
>       do we interprete LGPL too strict?

I think you are about right.

> I suppose that the following approach is conform to LGPL:
> Method 2:
> a) we download sources for libvirt.
> b) we compile themselves in our Windows environment
> c) we then distribute the binaries with our application.
> Of course we do the following:
>       we tell that we use libvirt
>       provide the license
>       provide copy right information
>       tell the customer that he has the right to receive sources (for three years after last distribution)
>       and/or provide sources together with binary.

This is the approach pretty much all Linux distributions follow, because by building everything from source yourself, you can ensure that you are in possession of all the pieces used to create the binaries & thus be able to distribute them for license compliance. If in doubt, I'd go for this approach of building everything from scratch.

Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--- Begin Message ---
  • Subject: Libvirt issues in windows
  • From: Ihar Smertsin <I.Smertsin@xxxxxxxxxxxxxxxxx>
  • Date: Tue, 8 Feb 2011 15:05:59 +0200
  • Accept-language: ru-RU, en-US
  • Acceptlanguage: ru-RU, en-US
  • Thread-index: AQHLx4FegfC5AnbOqESTTe36xqbfYg==
  • Thread-topic: Libvirt issues in windows
Hello Alexandr,

On the client version of the library under Windows detected the following errors:

1. When you call some library functions is a growth of handles of resources.
Growth handles can be found as follows:

   run the task manager;

   run the utility virsh;

   connect this tool to the server is running libvirtd service; (virsh -c qemu + tcp: / / 192.168.117.107/system)

   execute any command, for example list;

   if we continue to call a command list, then the task manager can be found that the number of handles will increase by about 5-6,

   The exact same situation arises every time you call some library functions, such as:
   virConnectListDomains, virConnectNumOfDomains, virDomainLookupByID, virDomainLookupByName and others;

2. In some cases, there is a growth of CPU resources. It happened in the following situations:
    We have a service that detects different types of virtual systems, including KVM.
    This service uses the client library libvirt. Our network has a host that is running windows 2008, which supports hyper-v virtualization.
    Our service is trying to determine the type of virtualization trying to connect to the system under different protocols.
    When the turn of the KVM, then there is the following situation. When we call the function virConnectOpen with parameter (qemu + tcp: / / 192.168.117.178:135 / system) error occurs. (Error: internal error received hangup / error event on socket)
    And then our service starts to take the CPU up to 20-25%.

--- End Message ---

--- End Message ---
--- Begin Message --- 
Hello Alexandr,

On the client version of the library under Windows detected the following errors:

1. When you call some library functions is a growth of handles of resources.
Growth handles can be found as follows:

   run the task manager;

   run the utility virsh;

   connect this tool to the server is running libvirtd service; (virsh -c qemu + tcp: / / 192.168.117.107/system)

   execute any command, for example list;

   if we continue to call a command list, then the task manager can be found that the number of handles will increase by about 5-6,

   The exact same situation arises every time you call some library functions, such as:
   virConnectListDomains, virConnectNumOfDomains, virDomainLookupByID, virDomainLookupByName and others;

2. In some cases, there is a growth of CPU resources. It happened in the following situations:
    We have a service that detects different types of virtual systems, including KVM.
    This service uses the client library libvirt. Our network has a host that is running windows 2008, which supports hyper-v virtualization.
    Our service is trying to determine the type of virtualization trying to connect to the system under different protocols.
    When the turn of the KVM, then there is the following situation. When we call the function virConnectOpen with parameter (qemu + tcp: / / 192.168.117.178:135 / system) error occurs. (Error: internal error received hangup / error event on socket)
    And then our service starts to take the CPU up to 20-25%.

--- End Message ---

Attachment: libvirt.log
Description: libvirt.log

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]