Re: vnstat / network wrong peaks while delete snapshot
2011/6/5 Reindl Harald h.rei...@thelounge.net: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman Maybe. I notice that the bad value is 16777216.00 TiB, which is 2**64 ... on a 64-bit machine. A quick look through the vnstat code shows that it is using floating point arithmetic with rounding to print this value, so that's exactly what I would expect to see if somebody managed to stuff -1 (or any other negative value of small magnitude) into an unsigned 64-bit variable. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
Am 06.06.2011 17:15, schrieb Jerry James: 2011/6/5 Reindl Harald h.rei...@thelounge.net: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman Maybe. I notice that the bad value is 16777216.00 TiB, which is 2**64 ... on a 64-bit machine. A quick look through the vnstat code shows that it is using floating point arithmetic with rounding to print this value, so that's exactly what I would expect to see if somebody managed to stuff -1 (or any other negative value of small magnitude) into an unsigned 64-bit variable. ok - so i should file a bugreport to vnstat if i understand you right? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
On Mon, Jun 6, 2011 at 9:19 AM, Reindl Harald h.rei...@thelounge.net wrote: ok - so i should file a bugreport to vnstat if i understand you right? I think so, yes. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
vnstat / network wrong peaks while delete snapshot
has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB |7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB |1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB |5.82 GiB |6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB |4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB |7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB |6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB |7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB |4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB |9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB |9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB |9.43 GiB | 10.94 GiB |1.06 Mbit/s 06/02/11906.48 MiB |5.90 GiB |6.79 GiB | 658.85 kbit/s 06/03/11 2.36 GiB |9.40 GiB | 11.77 GiB |1.14 Mbit/s 06/04/11 16777216.00 TiB |5.15 GiB | 16777216.00 TiB | 1668.00 Tbit/s 06/05/11585.88 MiB |2.30 GiB |2.87 GiB | 417.64 kbit/s +-+-+--- estimated 877 MiB |3.44 GiB |4.30 GiB | signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
is ifconfig showing this huge numberg at that time as well? do you have a 64bit OS or 32bit? did you try to report it to vmware as well? On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB |5.82 GiB |6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB |4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB |7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB |6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB |7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB | 4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB | 9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB | 9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB | 9.43 GiB | 10.94 GiB |1.06 Mbit/s 06/02/11906.48 MiB | 5.90 GiB |6.79 GiB | 658.85 kbit/s 06/03/11 2.36 GiB | 9.40 GiB | 11.77 GiB |1.14 Mbit/s 06/04/11 16777216.00 TiB |5.15 GiB | 16777216.00 TiB | 1668.00 Tbit/s 06/05/11585.88 MiB |2.30 GiB |2.87 GiB | 417.64 kbit/s +-+-+--- estimated 877 MiB |3.44 GiB |4.30 GiB | -- Lars Schotte @ Hana (F14) signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB |5.82 GiB |6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB |4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB |7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB |6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB |7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB | 4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB | 9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB | 9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB | 9.43 GiB | 10.94 GiB |1.06 Mbit/s 06/02/11906.48 MiB | 5.90 GiB |6.79 GiB | 658.85 kbit/s 06/03/11 2.36 GiB | 9.40 GiB | 11.77 GiB |1.14 Mbit/s 06/04/11 16777216.00 TiB |5.15 GiB | 16777216.00 TiB | 1668.00 Tbit/s 06/05/11585.88 MiB |2.30 GiB |2.87 GiB | 417.64 kbit/s +-+-+--- estimated 877 MiB |3.44 GiB |4.30 GiB | -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB |5.82 GiB |6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB |4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB |6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB | 7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB | 4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB | 9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB | 9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB | 9.43 GiB | 10.94 GiB |1.06 Mbit/s 06/02/11906.48 MiB | 5.90 GiB |6.79 GiB | 658.85 kbit/s 06/03/11 2.36 GiB | 9.40 GiB | 11.77 GiB |1.14 Mbit/s 06/04/11 16777216.00 TiB |5.15 GiB | 16777216.00 TiB | 1668.00 Tbit/s 06/05/11585.88 MiB |2.30 GiB |2.87 GiB | 417.64 kbit/s +-+-+--- estimated 877 MiB |3.44 GiB |4.30 GiB | -- Lars Schotte @ Hana (F14) signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
hm .. as i see it, it doesnt look like a vnstat bug to me. on 32bit maybe you have other corrupted data, because of the buffer overflow you dont notice it. i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB |5.82 GiB | 6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB | 4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB | 6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB | 7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB | 4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB | 9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB | 9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB | 9.43 GiB | 10.94 GiB |1.06 Mbit/s 06/02/11906.48 MiB | 5.90 GiB |6.79 GiB | 658.85 kbit/s 06/03/11 2.36 GiB | 9.40 GiB | 11.77 GiB |1.14 Mbit/s 06/04/11 16777216.00 TiB |5.15 GiB | 16777216.00 TiB | 1668.00 Tbit/s 06/05/11585.88 MiB | 2.30 GiB |2.87 GiB | 417.64 kbit/s +-+-+--- estimated 877 MiB |3.44 GiB |4.30 GiB | -- Lars Schotte @ Hana (F14) signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB |5.82 GiB | 6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB | 4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB | 6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB | 7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB | 4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB | 9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB | 9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB | 9.43 GiB | 10.94 GiB |1.06 Mbit/s 06/02/11906.48 MiB | 5.90 GiB |6.79 GiB | 658.85 kbit/s 06/03/11 2.36 GiB | 9.40 GiB | 11.77 GiB |1.14 Mbit/s 06/04/11 16777216.00 TiB |5.15 GiB | 16777216.00 TiB | 1668.00 Tbit/s 06/05/11585.88 MiB | 2.30 GiB |2.87 GiB | 417.64 kbit/s +-+-+--- estimated 877 MiB |3.44 GiB |
Re: vnstat / network wrong peaks while delete snapshot
so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB | 5.82 GiB | 6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB | 4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB | 6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB | 7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/29/11855.65 MiB | 4.89 GiB |5.72 GiB | 555.47 kbit/s 05/30/11 1.43 GiB | 9.20 GiB | 10.62 GiB |1.03 Mbit/s 05/31/11 1.77 GiB | 9.52 GiB | 11.29 GiB |1.10 Mbit/s 06/01/11 1.51 GiB | 9.43 GiB | 10.94 GiB |
Re: vnstat / network wrong peaks while delete snapshot
sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB | 5.82 GiB | 6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB | 4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB |6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11902.15 MiB | 6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26 Mbit/s 05/25/11 1.47 GiB |6.65 GiB |8.12 GiB | 788.78 kbit/s 05/26/11 1.23 GiB | 7.40 GiB |8.64 GiB | 838.46 kbit/s 05/27/11 1.43 GiB |6.75 GiB |8.19 GiB | 794.70 kbit/s 05/28/11 33554432.00 TiB |5.44 GiB | 33554432.00 TiB | 3336.00 Tbit/s
Re: vnstat / network wrong peaks while delete snapshot
thats exactly what vmware needs to comprehend. you dont need to tell me that ;-) On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB | 5.82 GiB | 6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB | 4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s 05/19/11 1.03 GiB |5.68 GiB | 6.72 GiB | 652.10 kbit/s 05/20/11 1.11 GiB |5.18 GiB |6.29 GiB | 610.67 kbit/s 05/21/11 16777216.00 TiB |3.97 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/22/11 902.15 MiB | 6.74 GiB |7.62 GiB | 739.58 kbit/s 05/23/11 1.28 GiB | 16.56 GiB | 17.84 GiB |1.73 Mbit/s 05/24/11 1.60 GiB | 11.42 GiB | 13.02 GiB |1.26
Re: vnstat / network wrong peaks while delete snapshot
Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see below :-( eth0 / daily day rx | tx |total| avg. rate +-+-+--- 05/07/11 16777216.00 TiB |5.56 GiB | 16777216.00 TiB | 1668.00 Tbit/s 05/08/11855.27 MiB |4.24 GiB |5.07 GiB | 492.63 kbit/s 05/09/11 2.35 GiB | 72.14 GiB | 74.49 GiB | 7.23 Mbit/s 05/10/11 1.47 GiB | 11.41 GiB | 12.88 GiB | 1.25 Mbit/s 05/11/11 1.11 GiB |6.19 GiB |7.30 GiB | 708.76 kbit/s 05/12/11 1.17 GiB | 5.82 GiB | 6.99 GiB | 678.38 kbit/s 05/13/11 1.12 GiB |6.50 GiB |7.62 GiB | 739.88 kbit/s 05/14/11 33554432.00 TiB | 4.10 GiB | 33554432.00 TiB | 3336.00 Tbit/s 05/15/11778.85 MiB |4.45 GiB |5.21 GiB | 505.87 kbit/s 05/16/11 1.30 GiB | 7.37 GiB |8.67 GiB | 842.06 kbit/s 05/17/11 1.38 GiB |8.18 GiB |9.56 GiB | 928.20 kbit/s 05/18/11 1.21 GiB |6.83 GiB |8.04 GiB | 780.32 kbit/s
Re: vnstat / network wrong peaks while delete snapshot
well, the guest operating system is measuring traffic that doesnt exist. that is a good start. now, normally, operating systems do NOT measure traffic that doesnt exist, so there must be something wrong with the network card driver. guess what.. it is not ... because vmware emulates a network card which most operating systems have a (good) driver of. so we can rule out an operating system or a network device driver error. so we should ask vmware why they implemented crazy transfer rate emulation on that virtualized device while doing snapshots. which of course have nothing to do with the fact that there is a network device emulated or used. so for me it looks like vmware did brake it intentionally. why they shoud do sth like that? because they are ... different. On Sun, 05 Jun 2011 21:30:21 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the postman every night from friday to saturday from our fedora-vmware-guests is made a snapshot by VMware Data Recovery to take a consistent backup and while deleting the snapshot something triggers horrible wrong values to vnstat which makes monthly summary useless see
Re: vnstat / network wrong peaks while delete snapshot
yes and because you have NO CHANCE to get support for fedora from VMware the question is if this trigger can not be corrected somewhere in the guest that 16777216.00 TiB is impossible in some seconds is clear - so my question was not to discuss where the problem is, my question is if it can be pragmatic fixed somewhere Am 05.06.2011 22:32, schrieb Lars Schotte: well, the guest operating system is measuring traffic that doesnt exist. that is a good start. now, normally, operating systems do NOT measure traffic that doesnt exist, so there must be something wrong with the network card driver. guess what.. it is not ... because vmware emulates a network card which most operating systems have a (good) driver of. so we can rule out an operating system or a network device driver error. so we should ask vmware why they implemented crazy transfer rate emulation on that virtualized device while doing snapshots. which of course have nothing to do with the fact that there is a network device emulated or used. so for me it looks like vmware did brake it intentionally. why they shoud do sth like that? because they are ... different. On Sun, 05 Jun 2011 21:30:21 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well? they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( On Sun, 05 Jun 2011 16:06:48 +0200 Reindl Harald h.rei...@thelounge.net wrote: has anybody an idea for which package i should file a bugreport for this? i guess vnstat is only the
Re: vnstat / network wrong peaks while delete snapshot
did you install some vmware software / drivers on the guest? On Sun, 05 Jun 2011 22:39:30 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes and because you have NO CHANCE to get support for fedora from VMware the question is if this trigger can not be corrected somewhere in the guest that 16777216.00 TiB is impossible in some seconds is clear - so my question was not to discuss where the problem is, my question is if it can be pragmatic fixed somewhere Am 05.06.2011 22:32, schrieb Lars Schotte: well, the guest operating system is measuring traffic that doesnt exist. that is a good start. now, normally, operating systems do NOT measure traffic that doesnt exist, so there must be something wrong with the network card driver. guess what.. it is not ... because vmware emulates a network card which most operating systems have a (good) driver of. so we can rule out an operating system or a network device driver error. so we should ask vmware why they implemented crazy transfer rate emulation on that virtualized device while doing snapshots. which of course have nothing to do with the fact that there is a network device emulated or used. so for me it looks like vmware did brake it intentionally. why they shoud do sth like that? because they are ... different. On Sun, 05 Jun 2011 21:30:21 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8, so you are saying that you run vnstat on the guests? On Sun, 05 Jun 2011 16:16:44 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:12, schrieb Lars Schotte: is ifconfig showing this huge numberg at that time as well? not currently, but i have seen such outputs in ifconfig too do you have a 64bit OS or 32bit? seems only affect x86_64 guests good input - the voip-machine is the only 32bit and does not show this did you try to report it to vmware as well?
Re: vnstat / network wrong peaks while delete snapshot
as wrote in my second post yes, because VMwareDataRecovery can not work without vmware-tools, the drivers are NOT from external packages because they are native supported from recent kernels PLEASE can we both stop this now? it is useless, there is nothing on the side of ESXi / VMware i can change, so what are we discuss here? 03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 0b:00.0 Serial Attached SCSI controller: VMware PVSCSI SCSI Controller (rev 02) they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( Am 05.06.2011 23:17, schrieb Lars Schotte: did you install some vmware software / drivers on the guest? On Sun, 05 Jun 2011 22:39:30 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes and because you have NO CHANCE to get support for fedora from VMware the question is if this trigger can not be corrected somewhere in the guest that 16777216.00 TiB is impossible in some seconds is clear - so my question was not to discuss where the problem is, my question is if it can be pragmatic fixed somewhere Am 05.06.2011 22:32, schrieb Lars Schotte: well, the guest operating system is measuring traffic that doesnt exist. that is a good start. now, normally, operating systems do NOT measure traffic that doesnt exist, so there must be something wrong with the network card driver. guess what.. it is not ... because vmware emulates a network card which most operating systems have a (good) driver of. so we can rule out an operating system or a network device driver error. so we should ask vmware why they implemented crazy transfer rate emulation on that virtualized device while doing snapshots. which of course have nothing to do with the fact that there is a network device emulated or used. so for me it looks like vmware did brake it intentionally. why they shoud do sth like that? because they are ... different. On Sun, 05 Jun 2011 21:30:21 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does only while snapshots are taken / removed there are some short untrue peaks which would be easaliy could filtered in the guest-software only by their hughe numbers which are clearly impossible and the problem is that this does not happen and so if some measuring says 20 GB in two seconds all averages are destroyed On Sun, 05 Jun 2011 16:20:16 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes! works perfectly, only after dealing with snapshots there are this horrible peaks on 64bit guests Am 05.06.2011 16:18, schrieb Lars Schotte: w8,
Re: vnstat / network wrong peaks while delete snapshot
hm, thats interesting, so the network controller is of a vmware's origin. try some other os, like for example netbsd with some real emulated network card, nothing from vmware, and see if the problem persists there as well. if not, then you know at least that the problem is not the kernel of the guest or some driver problem, but its vmware's fault. On Sun, 05 Jun 2011 23:25:05 +0200 Reindl Harald h.rei...@thelounge.net wrote: as wrote in my second post yes, because VMwareDataRecovery can not work without vmware-tools, the drivers are NOT from external packages because they are native supported from recent kernels PLEASE can we both stop this now? it is useless, there is nothing on the side of ESXi / VMware i can change, so what are we discuss here? 03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 0b:00.0 Serial Attached SCSI controller: VMware PVSCSI SCSI Controller (rev 02) they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( Am 05.06.2011 23:17, schrieb Lars Schotte: did you install some vmware software / drivers on the guest? On Sun, 05 Jun 2011 22:39:30 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes and because you have NO CHANCE to get support for fedora from VMware the question is if this trigger can not be corrected somewhere in the guest that 16777216.00 TiB is impossible in some seconds is clear - so my question was not to discuss where the problem is, my question is if it can be pragmatic fixed somewhere Am 05.06.2011 22:32, schrieb Lars Schotte: well, the guest operating system is measuring traffic that doesnt exist. that is a good start. now, normally, operating systems do NOT measure traffic that doesnt exist, so there must be something wrong with the network card driver. guess what.. it is not ... because vmware emulates a network card which most operating systems have a (good) driver of. so we can rule out an operating system or a network device driver error. so we should ask vmware why they implemented crazy transfer rate emulation on that virtualized device while doing snapshots. which of course have nothing to do with the fact that there is a network device emulated or used. so for me it looks like vmware did brake it intentionally. why they shoud do sth like that? because they are ... different. On Sun, 05 Jun 2011 21:30:21 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a ethernet-device with all features of a ethernet-device ond the guest does know nothing about virtualization maybe a vmware monitoring software would be more precise or an alternative would be to bind each to a virtual network card and do the monitoring on the host measuring only the output data and then routing all this devices out, thereby using the host as a router, which is of course a more complicated setup and i am not even sure if it would work, but thats the way i would try to build it up. jesus for what reason? the host is not a router, the host is a virtual switch and yes you have monitoring on the vCenter-Server but not in a console like output and not with exactly numbers this are two different worlds and i see no reason why vnstat would not work on the guest because it does
Re: vnstat / network wrong peaks while delete snapshot
Am 06.06.2011 00:09, schrieb Lars Schotte: hm, thats interesting, so the network controller is of a vmware's origin yes, we are speaking from a professional environment with newest software / hardware means ESXi 4.1 Update 1 witth latest patches, SAN-Storgae, vCenter-Clustering and latest generation of HP ProLiant--Hardware try some other os, like for example netbsd with some real emulated network card, nothing from vmware this is not interesting because there are 20 fedora production servers in the cluster and waht any other OS / hardware / software does is not relevant and see if the problem persists there as well. if not, then you know at least that the problem is not the kernel of the guest or some driver problem, but its vmware's fault. i know, but i can not get them to fix this and for the hope get a display error away you will not play on production systems so i am not interested in any theory what would happen somewhere else with any other guest system since if have this problem noticed since 2008 starting virtalize the whole company on ESXi 3.5 with vmxnet, in 2008 there was no clustering and this happend only sometimes while updating VMware-Tools i am searching for a pragmatic solution and if there is no one i can not change anything On Sun, 05 Jun 2011 23:25:05 +0200 Reindl Harald h.rei...@thelounge.net wrote: as wrote in my second post yes, because VMwareDataRecovery can not work without vmware-tools, the drivers are NOT from external packages because they are native supported from recent kernels PLEASE can we both stop this now? it is useless, there is nothing on the side of ESXi / VMware i can change, so what are we discuss here? 03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01) 0b:00.0 Serial Attached SCSI controller: VMware PVSCSI SCSI Controller (rev 02) they will anser fedora is not official supported and open-vm-tools vom rpmfusion too on ESXi :-( Am 05.06.2011 23:17, schrieb Lars Schotte: did you install some vmware software / drivers on the guest? On Sun, 05 Jun 2011 22:39:30 +0200 Reindl Harald h.rei...@thelounge.net wrote: yes and because you have NO CHANCE to get support for fedora from VMware the question is if this trigger can not be corrected somewhere in the guest that 16777216.00 TiB is impossible in some seconds is clear - so my question was not to discuss where the problem is, my question is if it can be pragmatic fixed somewhere Am 05.06.2011 22:32, schrieb Lars Schotte: well, the guest operating system is measuring traffic that doesnt exist. that is a good start. now, normally, operating systems do NOT measure traffic that doesnt exist, so there must be something wrong with the network card driver. guess what.. it is not ... because vmware emulates a network card which most operating systems have a (good) driver of. so we can rule out an operating system or a network device driver error. so we should ask vmware why they implemented crazy transfer rate emulation on that virtualized device while doing snapshots. which of course have nothing to do with the fact that there is a network device emulated or used. so for me it looks like vmware did brake it intentionally. why they shoud do sth like that? because they are ... different. On Sun, 05 Jun 2011 21:30:21 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 21:19, schrieb Lars Schotte: thats exactly what vmware needs to comprehend. WHAT should VMware do if the guest is measuring traffic which does not exist? you dont need to tell me that ;-) so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and your ideas solve this on the pysical layer or about routing on the host showing me that you have never worked with a ESXi-Cluster i try to solve a little problem IN THE GUEST and not to change the whole infrastructure because this would change exactly nothing on the vnstat-problem On Sun, 05 Jun 2011 20:55:53 +0200 Reindl Harald h.rei...@thelounge.net wrote: sorry to say but you have no idea what about i am speaking snapshots are not taken through that virtualized ethernet device the guest is freezed for a short time to take a consistent state of his drives which are copied on the host, the copy has NOTHING to to with the ethernet device in the guest Am 05.06.2011 20:50, schrieb Lars Schotte: so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices. maybe an extra ethernet device would help. the first one left for that snapshots fiction and second for networking. On Sun, 05 Jun 2011 20:34:49 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 16:55, schrieb Lars Schotte: i definitely wouldnt come to that idea to monitor guests on guests w/ vnstat because even if it had worked perfectly, its still just a fictional ethernet device. what is there fictional? it is a
Re: vnstat / network wrong peaks while delete snapshot
On Mon, Jun 06, 2011 at 12:09:24AM +0200, Lars Schotte wrote: hm, thats interesting, so the network controller is of a vmware's origin. try some other os, like for example netbsd with some real emulated network card, nothing from vmware, and see if the problem persists there as well. if not, then you know at least that the problem is not the kernel of the guest or some driver problem, but its vmware's fault. Maybe you are not aware that vmxnet driver is part of mainline kernel from some time. -- Tomasz TorczFuneral in the morning, IDE hacking xmpp: zdzich...@chrome.plin the afternoon and evening. - Alan Cox -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
Am 06.06.2011 00:18, schrieb Tomasz Torcz: On Mon, Jun 06, 2011 at 12:09:24AM +0200, Lars Schotte wrote: hm, thats interesting, so the network controller is of a vmware's origin. try some other os, like for example netbsd with some real emulated network card, nothing from vmware, and see if the problem persists there as well. if not, then you know at least that the problem is not the kernel of the guest or some driver problem, but its vmware's fault. Maybe you are not aware that vmxnet driver is part of mainline kernel from some time i try to tell him since hours that he has no plan about ESXi/Virtual Hardware nor Snapshots especially after the glamorous so you have to somehow convince vmware not to take snapshots through that virtualized ethernet devices and that i am not interested in theory this display errors are ugly but no reason to change anything in a perfectly working infrastructure in dimensions of many ten thousands of euro signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vnstat / network wrong peaks while delete snapshot
well, then it must be opensource, so maybe thats not the problem, maybe it listens to something it shouldnt. On Mon, 6 Jun 2011 00:18:14 +0200 Tomasz Torcz to...@pipebreaker.pl wrote: On Mon, Jun 06, 2011 at 12:09:24AM +0200, Lars Schotte wrote: hm, thats interesting, so the network controller is of a vmware's origin. try some other os, like for example netbsd with some real emulated network card, nothing from vmware, and see if the problem persists there as well. if not, then you know at least that the problem is not the kernel of the guest or some driver problem, but its vmware's fault. Maybe you are not aware that vmxnet driver is part of mainline kernel from some time. -- Lars Schotte @ Hana (F14) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
