RE: VIMAGE, epair/if_bridge or netgraph?
-Original Message- From: Palle Girgensohn [mailto:gir...@freebsd.org] Sent: Monday, March 31, 2014 4:44 AM To: dte...@freebsd.org Cc: freebsd-virtualization@FreeBSD.org Subject: Re: VIMAGE, epair/if_bridge or netgraph? 29 mar 2014 kl. 19:08 skrev dte...@freebsd.org: -Original Message- From: dte...@freebsd.org [mailto:dte...@freebsd.org] Sent: Saturday, March 29, 2014 10:58 AM To: 'Palle Girgensohn' Cc: freebsd-virtualization@FreeBSD.org; 'Devin Teske' Subject: RE: VIMAGE, epair/if_bridge or netgraph? -Original Message- From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd- virtualizat...@freebsd.org] On Behalf Of Palle Girgensohn Sent: Monday, June 11, 2012 2:37 PM To: freebsd-virtualization@FreeBSD.org Subject: VIMAGE, epair/if_bridge or netgraph? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm updating some jail servers, and want to use VIMAGE. Compiled it into the kernel, learned the hard way not to even include PF in the same kernel [1], so now it works quite well. I am setting up many similar jails, some for testing, some for production. The applications are web servers, som tomcat+apache's, and some other standard type of services like email and ldap, simple stuff. I need no fancy network control, I just need it to work. For each jail there are two interfaces, one public, connected to a software bridge (if_bridge or ng_bridge) acting as a switch, and one internal, for maintenance, connected to a different software bridge. To each software bridge, I connect a physical external interface from the jail host. I am trying to decide whether to use epair and if_bridge, or to use netgraph. For netgraph, there is a nice package at DruidBSD [3]. When I found that, I had already rewritten the standard jail script, using the v2 patches from polymorf [4]. They work equally fine for my purpose. So now I need to know which scales best, is there a difference in performance or stability between netgraph and epair/if_bridge? Cheers, Palle [1] https://urldefense.proofpoint.com/v1/url?u=http://forums.freebsd.org /showthread.php?t%3D31765k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D %0Ar=Mr js6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=55OQxWzTO24ZzksQHz%2Bx0S %2BolAmp ovPuqBDL%2FSJ3eiM%3D%0As=14d4e7005de0720881a8a37c21d7738c5efac 19fd3 6a40fd9d86339469412b1c [2] https://urldefense.proofpoint.com/v1/url?u=http://forums.freebsd.org /showthread.php?t%3D31949k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D %0Ar=Mr js6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=55OQxWzTO24ZzksQHz%2Bx0S %2BolAmp ovPuqBDL%2FSJ3eiM%3D%0As=526e98adfe7b28bb2e9387eda1ad4745c142 4e8662 2109a1b26d53e1ed4526b3 [3] https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.sourcefor ge.net/vimage.shtmlk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar= Mrjs6vR4 %2Faj2Ns9%2FssHJjg%3D%3D%0Am=55OQxWzTO24ZzksQHz%2Bx0S%2Bol AmpovPuqB DL%2FSJ3eiM%3D%0As=fa628e6b3896b8f1b75b2eda070a9b65375e564e736 21da1 ddf12c18fe56c612 [4] https://urldefense.proofpoint.com/v1/url?u=http://wiki.polymorf.fr/i ndex.php?title%3DHowto:FreeBSD_jail_vnetk=%2FbkpAUdJWZuiTILCq%2F FnQ g%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=55OQxWz TO24ZzksQH z%2Bx0S%2BolAmpovPuqBDL%2FSJ3eiM%3D%0As=2762f34c39dd7b58b8b3 98d89fa 0f7fe7e4900978664f25eafb66e1d4aedcdeb [Devin Teske] Never saw a reply to this and I'm locating round-tuits to tackle e-mails that I've marked as needing reply: I have not profiled Ugh, that was originally I have not profiled [epair but I have profiled] netgraph -- Cheers, Devin netgraph to have a limitation of 65530 eiface devices off a single if_bridge, but are allowed multiple bridges with that many devices. The problems that you run into with that many devices is that if all the interfaces are visible to a single jail or single host... your ifconfig command could take several hours (about 4) to enumerate each iface to the screen. I didn't mess much with epair because it failed to produce a situation where I could speak separate subnets over the same wire. Netgraph made it easy by way of being able to enable promiscuous and disable the autosrc feature (as you perhaps already found in my code you linked to above). -- Cheers, Devin Thanks for the response. I have since created a setup with epair, only to abandon it and pursue a setup with netgraph instead. I can't yet say which will best serve my needs, I can get back to that when I have more data. I do know that shutting down a jail that has epairs enabled very likely will panic the kernel. I'm not certain that netgraph is any different, but I have no data yey. I do know that some fixes have been made to kernel to avoid crashes. I'll get back with more info as I have more info to reveal. :) In my experience (which has been with 8.1, 8.3, 8.4, stable/8, 9.0,
RE: MAC addresses to use for BHyve VM's running under FreeBSD?
-Original Message- From: Craig Rodrigues [mailto:rodr...@freebsd.org] Sent: Tuesday, February 4, 2014 11:03 PM To: George Neville-Neil Cc: freebsd-virtualization@freebsd.org Subject: MAC addresses to use for BHyve VM's running under FreeBSD? Hi, I am running many BHyve VM's and am using tap interfaces with a single bridge. I am configuring the IP addresses of these VM's via DHCP. I need to have separate MAC addresses for each VM. Can anyone recommend a range of MAC addresses to use? I seem to recall that at the 2013 FreeBSD Vendor Summit in Sunnyvale, California, that George mentioned that there might be a Organizational Unique Identifier (OUI) for the FreeBSD project that we can use for BHyve VM's. Is that right? If not, can people recommend a range of addresses to use? [Devin Teske] I read a bunch of RFCs on how manufacturers form their MAC addresses. There is a range of values that will indicate privately administered MAC to networking equipment. In my testing over 6 years, I've found that these privately administered MAC addresses are not only treated well (read: no issues), but in some cases they hold their DHCP leases far longer than those without this special bit set. In my vimage script: http://druidbsd.sourceforge.net/download.shtml#vimage I have the following formula: # # Set the MAC address of the new interface using a sensible # algorithm to prevent conflicts on the network. # # MAC LAYOUT LP:LL:LB:BB:BB:BB # # Where: # P2, 6, A, or E but usually 2 # NOTE: Indicates privately administered MAC # Lng_bridge(4) link number (1-65535) # BSame as bridged interface # So if we think of a MAC address as 6 octets, there are three goals that this formula/layout is addressing: Goal 1: Set the P nibble to a value of 2, 6, A, or E to indicate that the MaC address is one that is privately administered Goal 2: Allow up to 65530** unique MAC addresses to be formed from one single bridged interface. ** This number comes from stress-testing the ng_bridge(4) interface. In a lab, we were able to generate 65530 peers, all visible with ifconfig(8) and ngctl(8). Goal 3: Make the child MAC address look as similar to the parent MAC while satisfying goal 1 and goal 2. It is Goal #2 that gives us the layout requirement to have 2 octets (4 nibbles, aka 16 bits) to store a numeric identifier for a unique MAC address. It is goal #3 that gives us the layout requirement to copy (unmodified) bits from the bridge interface into the child MAC address. However, it is Goal #1 (of utmost importance in our needs) to force the second nibble of the first octet (high order; P in the layout) to a certain value. It was my own personal preference to simply split the 4 nibbles for child identifier so I could group the nibbles from the parent MAC. Resulting in the layout: LP:LL:LB:BB:BB Again, where the disjoint LL:LL represents a number 0-65535 for the LINK or CHILD identifier (first peer is 0, second is 1, so-on), P is locked at 2 (but could easily expand to also use 6, A, or E), and B:BB:BB are bits from the bridge's MAC. For code on calculating it all, see the above link -- written in shell script using bit- wise masking. I think it needless to say that we went overboard... a single system could potentially run 262,120 vimages (dup the vimage rc.d 3x and change the privately administered MAC nibble ``P'' from 2 to 6, then A, then E; each gaining up to 65530 new privately administered MAC address space). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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: Bhyve infos about a vm
-Original Message- From: Andrea Brancatelli [mailto:abrancate...@schema31.it] Sent: Tuesday, January 14, 2014 9:27 AM To: Markiyan Kushnir Cc: freebsd-virtualization@freebsd.org Subject: Re: Bhyve infos about a vm I don't think so. I'm interested in seeing what ISO or IMG are attached i dont' see any such info here... mdconfig -lv ? -- Devin [root@environment-rm-01 /repository]# fstat -p `pgrep bhyve` USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root bhyve 4212 text /1044852 -r-xr-xr-x 318469 r root bhyve 4212 ctty /dev132 crw--w pts/3 rw root bhyve 4212 wd /repository 14 drwxr-xr-x 6 r root bhyve 4212 root / 2 drwxr-xr-x1024 r root bhyve 42120 /dev132 crw--w pts/3 rw root bhyve 42121 /dev132 crw--w pts/3 rw root bhyve 42122 /dev132 crw--w pts/3 rw root bhyve 42123 /dev138 crw--- vmm/lin1 rw root bhyve 42124 /repository 34 -rw-r--r-- 10737418240 rw root bhyve 42125 /dev140 crw---tap1 rw root bhyve 42126 /repository 45 -rw-r--r-- 652214272 rw root bhyve 42127 root bhyve 42128* pipe f80021dbf000 - f80021dbf160 0 rw root bhyve 42129* pipe f80021dbf160 - f80021dbf000 0 rw On Tue, Jan 14, 2014 at 5:54 PM, Markiyan Kushnir markiyan.kush...@gmail.com wrote: may be fstat -p `pgrep bhyve` would give you some info? -- Markiyan 2014/1/14 Andrea Brancatelli abrancate...@schema31.it: How should I see it with ps? [root@environment-rm-01 ~]# ps -aux | grep bhyve root 88142.4 0.0 4221912 60804 3 D+1:15PM3:11.43 bhyve: lin3 (bhyve) root 61870.0 0.0 4221784 34900 0 D+ 11:09AM0:52.81 bhyve: FreeBSD10.5RC5.img (bhyve) root 88630.0 0.0 18724 2156 4 S+1:22PM0:00.00 grep bhyve root 80080.0 0.0 4221912 54324 2 D+ 12:50PM0:48.50 bhyve: lin1 (bhyve) [root@environment-rm-01 ~]# cat /proc/6187/cmdline bhyve: FreeBSD10.5RC5.img I'm out of ideas... :) On Mon, Jan 13, 2014 at 8:29 PM, Peter Grehan gre...@freebsd.org wrote: Hi Andrea, Whats the command to list all the attached devices to a vm? The only way currently is to list the bhyve command line using ps. Any preferences for how you'd like to see this ? later, Peter. -- *Andrea BrancatelliSchema 31 S.r.l. - Socio UnicoResponsabile ITROMA - FIRENZE - PALERMO ITALYTel: +39. 06.98.358.472* *Cell: +39 331.2488468Fax: +39. 055.71.880.466Società del Gruppo SC31 ITALIA* ___ 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 -- *Andrea BrancatelliSchema 31 S.r.l. - Socio UnicoResponsabile ITROMA - FIRENZE - PALERMO ITALYTel: +39. 06.98.358.472* *Cell: +39 331.2488468Fax: +39. 055.71.880.466Società del Gruppo SC31 ITALIA* ___ 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 _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ 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
