how is the MAC for tap(4) computed?
There seems to be a very high rate of MAC address collisions when tap is running on different machines is there anyway to make the selection of MAC more random ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Current problem reports assigned to freebsd-virtualization@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/165252 virtualization[vimage] [pf] [panic] kernel panics with VIMAGE and PF o kern/161094 virtualization[vimage] [pf] [panic] kernel panic with pf + VIMAGE wh o kern/160541 virtualization[vimage][pf][patch] panic: userret: Returning on td 0x o kern/160496 virtualization[vimage] [pf] [patch] kernel panic with pf + VIMAGE o kern/148155 virtualization[vimage] [pf] Kernel panic with PF + VIMAGE kernel opt a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail 7 problems total. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: how is the MAC for tap(4) computed?
Hi Aryeh, There seems to be a very high rate of MAC address collisions when tap is running on different machines is there anyway to make the selection of MAC more random Do you mean, tap(4) when used with bhyve ? If so, bhyve calculates the MAC address for adapters based on an md5 hash of the PCI slot/function and VM name. If you use the same bhyve configuration on a different machine, the MAC address will be the same. If that's the problem, you may want to supply your own MAC address with the mac= parameter on the command line e.g. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: how is the MAC for tap(4) computed?
In the last episode (Nov 04), Aryeh Friedman said: There seems to be a very high rate of MAC address collisions when tap is running on different machines is there anyway to make the selection of MAC more random It looks like it's generated based on the number of ticks since boot, plus the unit number of the tap device: http://fxr.watson.org/fxr/source/net/if_tap.c#L434 So if you have devices created on boot on a bunch of machines, chances are high that you'll get conflicts. Maybe instead of using the 'ticks' value, kern.hostid could be used instead? That has much better randomness than 'ticks'. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: how is the MAC for tap(4) computed?
On 4 November 2013 12:09, Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Nov 04), Aryeh Friedman said: There seems to be a very high rate of MAC address collisions when tap is running on different machines is there anyway to make the selection of MAC more random It looks like it's generated based on the number of ticks since boot, plus the unit number of the tap device: http://fxr.watson.org/fxr/source/net/if_tap.c#L434 So if you have devices created on boot on a bunch of machines, chances are high that you'll get conflicts. Maybe instead of using the 'ticks' value, kern.hostid could be used instead? That has much better randomness than 'ticks'. With physical interfaces you can use something like ifconfig ath0 ether 00:2d:44:88:ff:00 (assuming the device the driver support changing MAC addresses) I've never tried it with a virtual interface, but it should work if the device supports it. -- -- ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Hyper-V
Hi! I upgraded to 10.0-BETA3 but still see messages like Tue Nov 5 11:09:05 MSK 2013 calcru: runtime went backwards from 1728 usec to 889 usec for pid 981 (zabbix_server) calcru: runtime went backwards from 1229 usec to 703 usec for pid 976 (zabbix_server) calcru: runtime went backwards from 1019 usec to 595 usec for pid 978 (zabbix_server) calcru: runtime went backwards from 3041 usec to 1611 usec for pid 969 (zabbix_server) calcru: runtime went backwards from 1078 usec to 595 usec for pid 975 (zabbix_server) calcru: runtime went backwards from 1114 usec to 617 usec for pid 980 (zabbix_server) calcru: runtime went backwards from 1086 usec to 602 usec for pid 977 (zabbix_server) calcru: runtime went backwards from 1195 usec to 782 usec for pid 970 (zabbix_server) calcru: runtime went backwards from 3206 usec to 2157 usec for pid 979 (zabbix_server) calcru: runtime went backwards from 2179 usec to 1542 usec for pid 972 (zabbix_server) calcru: runtime went backwards from 1833 usec to 927 usec for pid 1026 (cron) calcru: runtime went backwards from 1091 usec to 551 usec for pid 1022 (sendmail) calcru: runtime went backwards from 823 usec to 416 usec for pid 1022 (sendmail) calcru: runtime went backwards from 4691 usec to 2735 usec for pid 1011 (sendmail) calcru: runtime went backwards from 1162 usec to 587 usec for pid 1011 (sendmail) calcru: runtime went backwards from 947 usec to 478 usec for pid 1010 (httpd) calcru: runtime went backwards from 895 usec to 452 usec for pid 1009 (httpd) calcru: runtime went backwards from 954 usec to 482 usec for pid 1008 (httpd) calcru: runtime went backwards from 909 usec to 459 usec for pid 1007 (httpd) calcru: runtime went backwards from 1214 usec to 653 usec for pid 1006 (httpd) calcru: runtime went backwards from 201793 usec to 102672 usec for pid 996 (httpd) calcru: runtime went backwards from 1105 usec to 1064 usec for pid 991 (sshd) calcru: runtime went backwards from 45196 usec to 23221 usec for pid 974 (zabbix_server) calcru: runtime went backwards from 2192 usec to 1436 usec for pid 973 (zabbix_server) calcru: runtime went backwards from 605 usec to 306 usec for pid 968 (zabbix_server) calcru: runtime went backwards from 626 usec to 316 usec for pid 967 (zabbix_server) calcru: runtime went backwards from 773 usec to 391 usec for pid 966 (zabbix_server) calcru: runtime went backwards from 663 usec to 335 usec for pid 965 (zabbix_server) calcru: runtime went backwards from 799 usec to 404 usec for pid 964 (zabbix_server) calcru: runtime went backwards from 37723 usec to 19422 usec for pid 963 (zabbix_server) calcru: runtime went backwards from 49425 usec to 26265 usec for pid 962 (zabbix_server) calcru: runtime went backwards from 38883 usec to 20993 usec for pid 961 (zabbix_server) calcru: runtime went backwards from 53478 usec to 27411 usec for pid 960 (zabbix_server) calcru: runtime went backwards from 40845 usec to 21750 usec for pid 959 (zabbix_server) calcru: runtime went backwards from 47835 usec to 24455 usec for pid 958 (zabbix_server) calcru: runtime went backwards from 2257 usec to 1612 usec for pid 957 (zabbix_server) calcru: runtime went backwards from 2361 usec to 1193 usec for pid 932 (zabbix_agentd) calcru: runtime went backwards from 32053 usec to 16204 usec for pid 928 (zabbix_server) calcru: runtime went backwards from 32517 usec to 19280 usec for pid 697 (sh) calcru: runtime went backwards from 1128021 usec to 868022 usec for pid 697 (sh) calcru: runtime went backwards from 9609 usec to 5601 usec for pid 601 (syslogd) calcru: runtime went backwards from 688 usec to 348 usec for pid 106 (adjkerntz) calcru: runtime went backwards from 12 usec to 6 usec for pid 3 (sctp_iterator) calcru: runtime went backwards from 5467 usec to 2853 usec for pid 2 (fdc0) calcru: runtime went backwards from 11306 usec to 8408 usec for pid 14 (rand_harvestq) calcru: runtime went backwards from 136242 usec to 76230 usec for pid 13 (geom) calcru: runtime went backwards from 156117 usec to 118882 usec for pid 12 (intr) calcru: runtime went backwards from 7820 usec to 4847 usec for pid 1 (init) calcru: runtime went backwards from 2340313 usec to 1226503 usec for pid 1 (init) calcru: runtime went backwards from 4114 usec to 2164 usec for pid 0 (kernel) Is it bad? Or I have to ignore them? ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
