So I will still have the memory leak? On Feb 1, 2016 12:39 PM, "Simone Tiraboschi" <[email protected]> wrote:
> > > On Mon, Feb 1, 2016 at 6:33 PM, Charles Kozler <[email protected]> > wrote: > >> So what about the bug that I hit for vdsm as listed above by Nir? Will I >> have that patch to avoid the memory leak or no? Upgrading an entire node to >> centos 7 is not actually feasible and was previously outlined above that I >> just needed to upgrade to ovirt 3.6 and no mention of OS change ... >> > > You cannot install VDSM from 3.6 on el6: > > http://www.ovirt.org/OVirt_3.6_Release_Notes#RHEL_6.7_-_CentOS_6.7_and_similar > and there is no plan for a 3.5.8. > > > >> On Feb 1, 2016 12:30 PM, "Simone Tiraboschi" <[email protected]> wrote: >> >>> >>> >>> On Mon, Feb 1, 2016 at 5:40 PM, Charles Kozler <[email protected]> >>> wrote: >>> >>>> Sandro / Nir - >>>> >>>> I followed your steps plus >>>> >>>> http://www.ovirt.org/OVirt_3.6_Release_Notes#Fedora_.2F_CentOS_.2F_RHEL >>>> >>>> Engine upgraded fine but then when I got to upgrading a node I did: >>>> >>>> $ yum install >>>> http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm >>>> $ yum update -y >>>> >>>> And then rebooted the node. I noticed libvirt was updated by a .1 >>>> release number but vdsm (where the memory leak issue I thought was?) was >>>> not upgraded. In fact, very little of ovirt packages on the node were >>>> noticeably not updated >>>> >>>> >>> We are not building vdsm for el6 in 3.6, you need also to upgrade to el7 >>> if you want that. >>> >>> >>>> Updated node received the following updated packages during the install: >>>> >>>> http://pastebin.ca/3362714 >>>> >>>> Note specifically the only packages updated via the ovirt3.6 repository >>>> was ioprocess, otopi, ovirt-engine-sdk-python, ovirt-host-deploy, >>>> ovirt-release36, and python-ioprocess. I had expected to see some packages >>>> like vdsm and the likes updated - or was this not the case? >>>> >>>> Upgraded node: >>>> >>>> [compute[root@node02 yum.repos.d]$ rpm -qa | grep -i vdsm >>>> vdsm-4.16.30-0.el6.x86_64 >>>> vdsm-python-zombiereaper-4.16.30-0.el6.noarch >>>> vdsm-cli-4.16.30-0.el6.noarch >>>> vdsm-yajsonrpc-4.16.30-0.el6.noarch >>>> vdsm-jsonrpc-4.16.30-0.el6.noarch >>>> vdsm-xmlrpc-4.16.30-0.el6.noarch >>>> vdsm-python-4.16.30-0.el6.noarch >>>> >>>> Nonupgraded node >>>> >>>> [compute[root@node01 ~]$ rpm -qa | grep -i vdsm >>>> vdsm-cli-4.16.30-0.el6.noarch >>>> vdsm-jsonrpc-4.16.30-0.el6.noarch >>>> vdsm-python-zombiereaper-4.16.30-0.el6.noarch >>>> vdsm-xmlrpc-4.16.30-0.el6.noarch >>>> vdsm-yajsonrpc-4.16.30-0.el6.noarch >>>> vdsm-4.16.30-0.el6.x86_64 >>>> vdsm-python-4.16.30-0.el6.noarch >>>> >>>> Also, the docs stated that the engine VM would migrate to the freshly >>>> upgraded node since it would have a higher number but it did not >>>> >>>> So I cant really confirm whether or not my issue will be resolved? Or >>>> that if the node was actually updated properly? >>>> >>>> Please advise on how to confirm >>>> >>>> Thank you! >>>> >>>> On Sat, Jan 23, 2016 at 12:55 AM, Charles Kozler <[email protected]> >>>> wrote: >>>> >>>>> Thanks Sandro. Should clarify my storage is external on a redundant >>>>> SAN. The steps I was concerned about was the actual upgrade. I tried to >>>>> upgrade before and it brought my entire stack crumbling down so I'm >>>>> hesitant. This bug seems like a huge bug that should at least somehow >>>>> backported if at all possible because, to me, it renders the entire 3.5.6 >>>>> branch unusable as no VMs can be deployed since OOM will eventually kill >>>>> them. In any case that's just my opinion and I'm a new user to ovirt. The >>>>> docs I followed originally got me going how I need and somehow didn't work >>>>> for 3.6 in the same fashion so naturally I'm hesitant to upgrade but >>>>> clearly have no option if I want to continue my infrastructure on ovirt. >>>>> Thank you again for taking the time out to assist me, I truly appreciate >>>>> it. I will try an upgrade next week and pray it all goes well :-) >>>>> On Jan 23, 2016 12:40 AM, "Sandro Bonazzola" <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 22, 2016 at 10:53 PM, Charles Kozler < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Sandro - >>>>>>> >>>>>>> Do you have available documentation that can support upgrading self >>>>>>> hosted? I followed this >>>>>>> http://community.redhat.com/blog/2014/10/up-and-running-with-ovirt-3-5/ >>>>>>> >>>>>>> Would it be as easy as installing the RPM and then running yum >>>>>>> upgrade? >>>>>>> >>>>>>> >>>>>> Note that mentioned article describes an unsupported hyperconverged >>>>>> setup running NFS over Gluster. >>>>>> That said, >>>>>> 1) put the hosted-engine storage domain into global maintenance mode >>>>>> 2) upgrade the engine VM >>>>>> 3) select the first host to upgrade and put it under maintenance from >>>>>> the engine, wait for the engine vm to migrate if needed. >>>>>> 4) yum upgrade the first host and wait until ovirt-ha-agent completes >>>>>> 5) exit global and local maintenance mode >>>>>> 6) repeat 3-5 on all the other hosts >>>>>> 7) once all hosts are updated you can increase the cluster >>>>>> compatibility level to 3.6. At this point the engine will trigger the >>>>>> auto-import of the hosted-engine storage domain. >>>>>> >>>>>> Simone, Roy, can you confirm above steps? Maybe also you can update >>>>>> http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine >>>>>> >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On Fri, Jan 22, 2016 at 4:42 PM, Sandro Bonazzola < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> Il 22/Gen/2016 22:31, "Charles Kozler" <[email protected]> ha >>>>>>>> scritto: >>>>>>>> > >>>>>>>> > Hi Nir - >>>>>>>> > >>>>>>>> > do you have a release target date for 3.5.8? Any estimate would >>>>>>>> help. >>>>>>>> > >>>>>>>> >>>>>>>> There won't be any supported release after 3.5.6. Please update to >>>>>>>> 3.6.2 next week >>>>>>>> >>>>>>>> > If its not VDSM, what is it exactly? Sorry, I understood from the >>>>>>>> ticket it was something inside vdsm, was I mistaken? >>>>>>>> > >>>>>>>> > CentOS 6 is the servers. 6.7 to be exact >>>>>>>> > >>>>>>>> > I have done all forms of flushing that I can (page cache, inodes, >>>>>>>> dentry's, etc) and as well moved VM's around to other nodes and nothing >>>>>>>> changes the memory. How can I find the leak? Where is the leak? RES >>>>>>>> shows >>>>>>>> the following of which, the totals dont add up to 20GB >>>>>>>> > >>>>>>>> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ >>>>>>>> COMMAND >>>>>>>> >>>>>>>> > 19044 qemu 20 0 8876m 4.0g 5680 S 3.6 12.9 1571:44 >>>>>>>> qemu-kvm >>>>>>>> >>>>>>>> > 26143 qemu 20 0 5094m 1.1g 5624 S 9.2 3.7 6012:12 >>>>>>>> qemu-kvm >>>>>>>> >>>>>>>> > 5837 root 0 -20 964m 624m 3664 S 0.0 2.0 85:22.09 >>>>>>>> glusterfs >>>>>>>> >>>>>>>> > 14328 root 0 -20 635m 169m 3384 S 0.0 0.5 43:15.23 >>>>>>>> glusterfs >>>>>>>> >>>>>>>> > 5134 vdsm 0 -20 4368m 111m 10m S 5.9 0.3 3710:50 >>>>>>>> vdsm >>>>>>>> >>>>>>>> > 4095 root 15 -5 727m 43m 10m S 0.0 0.1 0:02.00 >>>>>>>> supervdsmServer >>>>>>>> > >>>>>>>> > 4.0G + 1.1G + 624M + 169 + 111M + 43M = ~7GB >>>>>>>> > >>>>>>>> > This was top sorted by RES from highest to lowest >>>>>>>> > >>>>>>>> > At that point I wouldnt know where else to look except slab / >>>>>>>> kernel structures. Of which slab shows: >>>>>>>> > >>>>>>>> > [compute[root@node1 ~]$ cat /proc/meminfo | grep -i slab >>>>>>>> > Slab: 2549748 kB >>>>>>>> > >>>>>>>> > So roughly 2-3GB. Adding that to the other use of 7GB we have >>>>>>>> still about 10GB unaccounted for >>>>>>>> > >>>>>>>> > On Fri, Jan 22, 2016 at 4:24 PM, Nir Soffer <[email protected]> >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> On Fri, Jan 22, 2016 at 11:08 PM, Charles Kozler < >>>>>>>> [email protected]> wrote: >>>>>>>> >> > Hi Nir - >>>>>>>> >> > >>>>>>>> >> > Thanks for getting back to me. Will the patch to 3.6 be >>>>>>>> backported to 3.5? >>>>>>>> >> >>>>>>>> >> We plan to include them in 3.5.8. >>>>>>>> >> >>>>>>>> >> > As you can tell from the images, it takes days and days for it >>>>>>>> to increase >>>>>>>> >> > over time. I also wasnt sure if that was the right bug because >>>>>>>> VDSM memory >>>>>>>> >> > shows normal from top ... >>>>>>>> >> > >>>>>>>> >> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ >>>>>>>> COMMAND >>>>>>>> >> > 5134 vdsm 0 -20 4368m 111m 10m S 2.0 0.3 3709:28 >>>>>>>> vdsm >>>>>>>> >> >>>>>>>> >> As you wrote, this issue is not related to vdsm. >>>>>>>> >> >>>>>>>> >> > >>>>>>>> >> > Res is only 111M. This is from node1 which is showing >>>>>>>> currently 20GB of 32GB >>>>>>>> >> > used with only 2 VMs running on it - 1 with 4G and another >>>>>>>> with ~1 GB of RAM >>>>>>>> >> > configured >>>>>>>> >> > >>>>>>>> >> > The images are from nagios and the value here is a direct >>>>>>>> correlation to >>>>>>>> >> > what you would see in the free command output. See below from >>>>>>>> an example of >>>>>>>> >> > node 1 and node 2 >>>>>>>> >> > >>>>>>>> >> > [compute[root@node1 ~]$ free >>>>>>>> >> > total used free shared >>>>>>>> buffers cached >>>>>>>> >> > Mem: 32765316 20318156 12447160 252 >>>>>>>> 30884 628948 >>>>>>>> >> > -/+ buffers/cache: 19658324 13106992 >>>>>>>> >> > Swap: 19247100 0 19247100 >>>>>>>> >> > [compute[root@node1 ~]$ free -m >>>>>>>> >> > total used free shared >>>>>>>> buffers cached >>>>>>>> >> > Mem: 31997 19843 12153 0 >>>>>>>> 30 614 >>>>>>>> >> > -/+ buffers/cache: 19199 12798 >>>>>>>> >> > Swap: 18795 0 18795 >>>>>>>> >> > >>>>>>>> >> > And its correlated image http://i.imgur.com/PZLEgyx.png >>>>>>>> (~19GB used) >>>>>>>> >> > >>>>>>>> >> > And as a control, node 2 that I just restarted today >>>>>>>> >> > >>>>>>>> >> > [compute[root@node2 ~]$ free >>>>>>>> >> > total used free shared >>>>>>>> buffers cached >>>>>>>> >> > Mem: 32765316 1815324 30949992 212 >>>>>>>> 35784 717320 >>>>>>>> >> > -/+ buffers/cache: 1062220 31703096 >>>>>>>> >> > Swap: 19247100 0 19247100 >>>>>>>> >> >>>>>>>> >> Is this rhel/centos 6? >>>>>>>> >> >>>>>>>> >> > [compute[root@node2 ~]$ free -m >>>>>>>> >> > total used free shared >>>>>>>> buffers cached >>>>>>>> >> > Mem: 31997 1772 30225 0 >>>>>>>> 34 700 >>>>>>>> >> > -/+ buffers/cache: 1036 30960 >>>>>>>> >> > Swap: 18795 0 18795 >>>>>>>> >> > >>>>>>>> >> > And its correlated image http://i.imgur.com/8ldPVqY.png >>>>>>>> (~2GB used). Note >>>>>>>> >> > how 1772 in the image is exactly what is registered under >>>>>>>> 'used' in free >>>>>>>> >> > command >>>>>>>> >> >>>>>>>> >> I guess you should start looking at the processes running on >>>>>>>> these nodes. >>>>>>>> >> >>>>>>>> >> Maybe try to collect memory usage per process using ps? >>>>>>>> >> >>>>>>>> >> > >>>>>>>> >> > On Fri, Jan 22, 2016 at 3:59 PM, Nir Soffer < >>>>>>>> [email protected]> wrote: >>>>>>>> >> >> >>>>>>>> >> >> On Fri, Jan 22, 2016 at 9:25 PM, Charles Kozler < >>>>>>>> [email protected]> >>>>>>>> >> >> wrote: >>>>>>>> >> >> > Here is a screenshot of my three nodes and their increased >>>>>>>> memory usage >>>>>>>> >> >> > over >>>>>>>> >> >> > 30 days. Note that node #2 had 1 single VM that had 4GB of >>>>>>>> RAM assigned >>>>>>>> >> >> > to >>>>>>>> >> >> > it. I had since shut it down and saw no memory reclamation >>>>>>>> occur. >>>>>>>> >> >> > Further, I >>>>>>>> >> >> > flushed page caches and inodes and ran 'sync'. I tried >>>>>>>> everything but >>>>>>>> >> >> > nothing brought the memory usage down. vdsm was low too >>>>>>>> (couple hundred >>>>>>>> >> >> > MB) >>>>>>>> >> >> >>>>>>>> >> >> Note that there is an old leak in vdsm, will be fixed in next >>>>>>>> 3.6 build: >>>>>>>> >> >> https://bugzilla.redhat.com/1269424 >>>>>>>> >> >> >>>>>>>> >> >> > and there was no qemu-kvm process running so I'm at a loss >>>>>>>> >> >> > >>>>>>>> >> >> > http://imgur.com/a/aFPcK >>>>>>>> >> >> > >>>>>>>> >> >> > Please advise on what I can do to debug this. Note I have >>>>>>>> restarted node >>>>>>>> >> >> > 2 >>>>>>>> >> >> > (which is why you see the drop) to see if it raises in >>>>>>>> memory use over >>>>>>>> >> >> > tim >>>>>>>> >> >> > even with no VM's running >>>>>>>> >> >> >>>>>>>> >> >> Not sure what is "memory" that you show in the graphs. >>>>>>>> Theoretically this >>>>>>>> >> >> may be >>>>>>>> >> >> normal memory usage, Linux using free memory for the buffer >>>>>>>> cache. >>>>>>>> >> >> >>>>>>>> >> >> Can you instead show the output of "free", during one day, >>>>>>>> maybe run once >>>>>>>> >> >> per hour? >>>>>>>> >> >> >>>>>>>> >> >> You may also like to install sysstat for collecting and >>>>>>>> monitoring >>>>>>>> >> >> resources usage. >>>>>>>> >> >> >>>>>>>> >> >> > >>>>>>>> >> >> > [compute[root@node2 log]$ rpm -qa | grep -i ovirt >>>>>>>> >> >> > libgovirt-0.3.2-1.el6.x86_64 >>>>>>>> >> >> > ovirt-release35-006-1.noarch >>>>>>>> >> >> > ovirt-hosted-engine-ha-1.2.8-1.el6.noarch >>>>>>>> >> >> > ovirt-hosted-engine-setup-1.2.6.1-1.el6.noarch >>>>>>>> >> >> > ovirt-engine-sdk-python-3.5.6.0-1.el6.noarch >>>>>>>> >> >> > ovirt-host-deploy-1.3.2-1.el6.noarch >>>>>>>> >> >> > >>>>>>>> >> >> > >>>>>>>> >> >> > -- >>>>>>>> >> >> > >>>>>>>> >> >> > Charles Kozler >>>>>>>> >> >> > Vice President, IT Operations >>>>>>>> >> >> > >>>>>>>> >> >> > FIX Flyer, LLC >>>>>>>> >> >> > 225 Broadway | Suite 1600 | New York, NY 10007 >>>>>>>> >> >> > 1-888-349-3593 >>>>>>>> >> >> > http://www.fixflyer.com >>>>>>>> >> >> > >>>>>>>> >> >> > NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT ONLY FOR THE >>>>>>>> INTENDED >>>>>>>> >> >> > RECIPIENT(S) >>>>>>>> >> >> > OF THE TRANSMISSION, AND CONTAINS CONFIDENTIAL INFORMATION >>>>>>>> WHICH IS >>>>>>>> >> >> > PROPRIETARY TO FIX FLYER LLC. ANY UNAUTHORIZED USE, >>>>>>>> COPYING, >>>>>>>> >> >> > DISTRIBUTION, >>>>>>>> >> >> > OR DISSEMINATION IS STRICTLY PROHIBITED. ALL RIGHTS TO >>>>>>>> THIS INFORMATION >>>>>>>> >> >> > IS >>>>>>>> >> >> > RESERVED BY FIX FLYER LLC. IF YOU ARE NOT THE INTENDED >>>>>>>> RECIPIENT, >>>>>>>> >> >> > PLEASE >>>>>>>> >> >> > CONTACT THE SENDER BY REPLY E-MAIL AND PLEASE DELETE THIS >>>>>>>> E-MAIL FROM >>>>>>>> >> >> > YOUR >>>>>>>> >> >> > SYSTEM AND DESTROY ANY COPIES. >>>>>>>> >> >> > >>>>>>>> >> >> > _______________________________________________ >>>>>>>> >> >> > Users mailing list >>>>>>>> >> >> > [email protected] >>>>>>>> >> >> > http://lists.ovirt.org/mailman/listinfo/users >>>>>>>> >> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > -- >>>>>>>> >> > >>>>>>>> >> > Charles Kozler >>>>>>>> >> > Vice President, IT Operations >>>>>>>> >> > >>>>>>>> >> > FIX Flyer, LLC >>>>>>>> >> > 225 Broadway | Suite 1600 | New York, NY 10007 >>>>>>>> >> > 1-888-349-3593 >>>>>>>> >> > http://www.fixflyer.com >>>>>>>> >> > >>>>>>>> >> > NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT ONLY FOR THE >>>>>>>> INTENDED RECIPIENT(S) >>>>>>>> >> > OF THE TRANSMISSION, AND CONTAINS CONFIDENTIAL INFORMATION >>>>>>>> WHICH IS >>>>>>>> >> > PROPRIETARY TO FIX FLYER LLC. ANY UNAUTHORIZED USE, COPYING, >>>>>>>> DISTRIBUTION, >>>>>>>> >> > OR DISSEMINATION IS STRICTLY PROHIBITED. ALL RIGHTS TO THIS >>>>>>>> INFORMATION IS >>>>>>>> >> > RESERVED BY FIX FLYER LLC. IF YOU ARE NOT THE INTENDED >>>>>>>> RECIPIENT, PLEASE >>>>>>>> >> > CONTACT THE SENDER BY REPLY E-MAIL AND PLEASE DELETE THIS >>>>>>>> E-MAIL FROM YOUR >>>>>>>> >> > SYSTEM AND DESTROY ANY COPIES. >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > -- >>>>>>>> > >>>>>>>> > Charles Kozler >>>>>>>> > Vice President, IT Operations >>>>>>>> > >>>>>>>> > FIX Flyer, LLC >>>>>>>> > 225 Broadway | Suite 1600 | New York, NY 10007 >>>>>>>> > 1-888-349-3593 >>>>>>>> > http://www.fixflyer.com >>>>>>>> > >>>>>>>> > NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT ONLY FOR THE INTENDED >>>>>>>> RECIPIENT(S) OF THE TRANSMISSION, AND CONTAINS CONFIDENTIAL INFORMATION >>>>>>>> WHICH IS PROPRIETARY TO FIX FLYER LLC. ANY UNAUTHORIZED USE, COPYING, >>>>>>>> DISTRIBUTION, OR DISSEMINATION IS STRICTLY PROHIBITED. ALL RIGHTS TO >>>>>>>> THIS >>>>>>>> INFORMATION IS RESERVED BY FIX FLYER LLC. IF YOU ARE NOT THE INTENDED >>>>>>>> RECIPIENT, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND PLEASE DELETE >>>>>>>> THIS >>>>>>>> E-MAIL FROM YOUR SYSTEM AND DESTROY ANY COPIES. >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > Users mailing list >>>>>>>> > [email protected] >>>>>>>> > http://lists.ovirt.org/mailman/listinfo/users >>>>>>>> > >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Charles Kozler* >>>>>>> *Vice President, IT Operations* >>>>>>> >>>>>>> FIX Flyer, LLC >>>>>>> 225 Broadway | Suite 1600 | New York, NY 10007 >>>>>>> 1-888-349-3593 >>>>>>> http://www.fixflyer.com <http://fixflyer.com> >>>>>>> >>>>>>> NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT ONLY FOR THE INTENDED >>>>>>> RECIPIENT(S) OF THE TRANSMISSION, AND CONTAINS CONFIDENTIAL INFORMATION >>>>>>> WHICH IS PROPRIETARY TO FIX FLYER LLC. ANY UNAUTHORIZED USE, COPYING, >>>>>>> DISTRIBUTION, OR DISSEMINATION IS STRICTLY PROHIBITED. ALL RIGHTS TO >>>>>>> THIS >>>>>>> INFORMATION IS RESERVED BY FIX FLYER LLC. IF YOU ARE NOT THE INTENDED >>>>>>> RECIPIENT, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND PLEASE DELETE >>>>>>> THIS >>>>>>> E-MAIL FROM YOUR SYSTEM AND DESTROY ANY COPIES. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sandro Bonazzola >>>>>> Better technology. Faster innovation. Powered by community >>>>>> collaboration. >>>>>> See how it works at redhat.com >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Charles Kozler* >>>> *Vice President, IT Operations* >>>> >>>> FIX Flyer, LLC >>>> 225 Broadway | Suite 1600 | New York, NY 10007 >>>> 1-888-349-3593 >>>> http://www.fixflyer.com <http://fixflyer.com> >>>> >>>> NOTICE TO RECIPIENT: THIS E-MAIL IS MEANT ONLY FOR THE INTENDED >>>> RECIPIENT(S) OF THE TRANSMISSION, AND CONTAINS CONFIDENTIAL INFORMATION >>>> WHICH IS PROPRIETARY TO FIX FLYER LLC. ANY UNAUTHORIZED USE, COPYING, >>>> DISTRIBUTION, OR DISSEMINATION IS STRICTLY PROHIBITED. ALL RIGHTS TO THIS >>>> INFORMATION IS RESERVED BY FIX FLYER LLC. IF YOU ARE NOT THE INTENDED >>>> RECIPIENT, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND PLEASE DELETE THIS >>>> E-MAIL FROM YOUR SYSTEM AND DESTROY ANY COPIES. >>>> >>> >>> >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
