Re: MAC addresses to use for BHyve VM's running under FreeBSD?
Am 05.02.2014 um 08:03 schrieb Craig Rodrigues: 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? http://standards.ieee.org/develop/regauth/oui/public.html Using Search the Public MA-L Listing with search term FreeBSD reveals.. --- snip --- Here are the results of your search through the public section of the IEEE Standards OUI database report for freebsd: 58-9C-FC (hex) FreeBSD Foundation 589CFC (base 16) FreeBSD Foundation P.O. Box 20247 Boulder CO 80308-3247 UNITED STATES --- snap --- Regards, K. -- GPG-Key: A593 E38B E968 4DBE 14D6 2115 7065 4D7C 4FB1 F588 Key available from hkps://hkps.pool.sks-keyservers.net PGP.sig Description: Signierter Teil der Nachricht
Re: Bhyve and network virtualization
Thank you :) With crossbow, no GUI too. I always prefer cmd line thant gui :p Thank you for the document. Actually, i am testing the vde2 port ( http://www.freebsdports.info/ports/net/vde2.html). It's very interesting too for build a virtual network. -- fax 2014-02-05 Craig Rodrigues rodr...@freebsd.org: On Sat, Feb 1, 2014 at 1:03 AM, Frédéric Alix frederic.a...@fredalix.comwrote: Now, i need a tool for build a virtual network, like crossbow in Illumos. Well, it is not a graphical tool, but if you are OK with doing things from the command-line, you can create a bridge network device and create tap interfaces for each BHyve VM. Then inside your BHyve VM, you can use the vtnet driver (part of virtio) to access the network. Michael Dexter has written a nice document which explains how to do this and a lot more with BHyve: http://bhyve.org/bhyve-manual.pdf -- Craig ___ 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: MAC addresses to use for BHyve VM's running under FreeBSD?
On Feb 5, 2014, at 3:33 , Kai Gallasch k at free.de wrote:
Am 05.02.2014 um 08:03 schrieb Craig Rodrigues:
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?
http://standards.ieee.org/develop/regauth/oui/public.html
Using Search the Public MA-L Listing with search term FreeBSD reveals..
--- snip ---
Here are the results of your search through the public section of the IEEE
Standards OUI database report for freebsd:
58-9C-FC (hex) FreeBSD
Foundation
589CFC (base 16)
FreeBSD
Foundation
P.O. Box 20247
Boulder CO 80308-3247
UNITED STATES
--- snap ---
Correct, that is an address that the Foundation has registered with the IEEE.
If you look at sys/net/ieee_oui.h you will see that I’ve allocated a range to
bhyve already.
At work, we modified the bhyverun command to seed the hostname
of them machine running the hypervisor as part of the generate a MAC
address routine. That means that for virtual machine foo,
you now get different MACs on server bar and server baz.
Without this patch, you're likely to get identical MAC addresses
for virtual machine foo on different servers.
I personally also have my virtual machines set bit 2 in
the first octet of the MAC address, so it falls into the
locally administered catagory of MAC addresses. My gut feel
is that using the FreeBSD OUI bhyve range, *AND* setting the
locally administered bit in the MAC address is the way to go.
-Kurt
diff --git a/usr.sbin/bhyve/pci_virtio_net.c b/usr.sbin/bhyve/pci_virtio_net.c
--- a/usr.sbin/bhyve/pci_virtio_net.c
+++ b/usr.sbin/bhyve/pci_virtio_net.c
@@ -579,27 +579,36 @@ pci_vtnet_init(struct vmctx *ctx, struct
close(sc-vsc_tapfd);
sc-vsc_tapfd = -1;
}
}
}
/*
* The default MAC address is the standard NetApp OUI of 00-a0-98,
-* followed by an MD5 of the PCI slot/func number and dev name
+* followed by an MD5 of the PCI slot/func number, hostname, and
+* vmname. The locally administered bit is also set in the
+* resulting MAC address.
*/
if (!mac_provided) {
- snprintf(nstr, sizeof(nstr), %d-%d-%s, pi-pi_slot,
- pi-pi_func, vmname);
+ char hostname[MAXHOSTNAMELEN];
+ int rc;
+
+ rc = gethostname(hostname, sizeof hostname - 1);
+ if (rc 0)
+ hostname[0] = 0;
+ hostname[MAXHOSTNAMELEN-1] = 0;
+ snprintf(nstr, sizeof(nstr), %d-%d-%s-%s, pi-pi_slot,
+ pi-pi_func, hostname, vmname);
MD5Init(mdctx);
MD5Update(mdctx, nstr, strlen(nstr));
MD5Final(digest, mdctx);
- sc-vsc_config.mac[0] = 0x00;
+ sc-vsc_config.mac[0] = 0x00 | 0x2; /* locally administered */
sc-vsc_config.mac[1] = 0xa0;
sc-vsc_config.mac[2] = 0x98;
sc-vsc_config.mac[3] = digest[0];
sc-vsc_config.mac[4] = digest[1];
sc-vsc_config.mac[5] = digest[2];
}
/* initialize config space */
___
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 and network virtualization
Has anyone used VALE with bhyve yet? It's in 10.0-RELEASE http://info.iet.unipi.it/~luigi/vale/ On 2/5/2014 5:57 AM, Frédéric Alix wrote: Thank you :) With crossbow, no GUI too. I always prefer cmd line thant gui :p Thank you for the document. Actually, i am testing the vde2 port ( http://www.freebsdports.info/ports/net/vde2.html). It's very interesting too for build a virtual network. -- fax 2014-02-05 Craig Rodrigues rodr...@freebsd.org: On Sat, Feb 1, 2014 at 1:03 AM, Frédéric Alix frederic.a...@fredalix.comwrote: Now, i need a tool for build a virtual network, like crossbow in Illumos. Well, it is not a graphical tool, but if you are OK with doing things from the command-line, you can create a bridge network device and create tap interfaces for each BHyve VM. Then inside your BHyve VM, you can use the vtnet driver (part of virtio) to access the network. Michael Dexter has written a nice document which explains how to do this and a lot more with BHyve: http://bhyve.org/bhyve-manual.pdf -- Craig ___ 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: MAC addresses to use for BHyve VM's running under FreeBSD?
On Wed, Feb 5, 2014 at 9:46 AM, Kurt Lidl l...@pix.net wrote: On Feb 5, 2014, at 3:33 , Kai Gallasch k at free.de wrote: Am 05.02.2014 um 08:03 schrieb Craig Rodrigues: 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? http://standards.ieee.org/develop/regauth/oui/public.html Using Search the Public MA-L Listing with search term FreeBSD reveals.. --- snip --- Here are the results of your search through the public section of the IEEE Standards OUI database report for freebsd: 58-9C-FC (hex) FreeBSD Foundation 589CFC (base 16) FreeBSD Foundation P.O. Box 20247 Boulder CO 80308-3247 UNITED STATES --- snap --- Correct, that is an address that the Foundation has registered with the IEEE. If you look at sys/net/ieee_oui.h you will see that I've allocated a range to bhyve already. At work, we modified the bhyverun command to seed the hostname of them machine running the hypervisor as part of the generate a MAC address routine. That means that for virtual machine foo, you now get different MACs on server bar and server baz. Without this patch, you're likely to get identical MAC addresses for virtual machine foo on different servers. I personally also have my virtual machines set bit 2 in the first octet of the MAC address, so it falls into the locally administered catagory of MAC addresses. My gut feel is that using the FreeBSD OUI bhyve range, *AND* setting the locally administered bit in the MAC address is the way to go. b George, Thanks for allocating that range of MAC addresses. We shoud probably document that MAC address range in one of the BHyve man pages. Kurt, Your change is definitely useful. It changes the behavior of BHyve with respect to MAC addresses, but it is a very useful change. Have you submitted your change to Peter and Neel to see if they can evaluate if it can be made part of BHyve in the FreeBSD src tree? -- Craig ___ 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
Disks are not shown on Adaptec 5805 (added via passthrough to the VM)
Hello, I created a virtual machine with installed FreeBSD on ESXi 5.5. I added controller Adaptec 5805 to the VM via passthrough. FreeBSD detects aac controller but does not show disks. (it does not matter whether JBODs or logical volumes are configured on Adaptec) I did some tests and ex. it works well on Ubuntu - I can use all disks on controller which was added via passhrough to the virtual machine with Ubuntu. Everything works well under physical FreeBSD. logs: aac0: Adaptec RAID 5805 mem 0xfd20-0xfd3f irq 18 at device 0.0 on pci3 aac0: Enabling 64-bit address support aac0: Enable Raw I/O aac0: Enable 64-bit array aac0: New comm. interface enabled aac0: Adaptec 5805, aac driver 2.1.9-1 aacp0 on aac0 aacp1 on aac0 aacp2 on aac0 (probe2:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe2:aacp2:0:0:0): CAM status: CCB request completed with an error (probe2:aacp2:0:0:0): Retrying command (probe2:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe2:aacp2:0:0:0): CAM status: CCB request completed with an error (probe2:aacp2:0:0:0): Retrying command (probe2:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe2:aacp2:0:0:0): CAM status: CCB request completed with an error (probe2:aacp2:0:0:0): Retrying command (probe2:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe2:aacp2:0:0:0): CAM status: CCB request completed with an error (probe2:aacp2:0:0:0): Retrying command (probe2:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe2:aacp2:0:0:0): CAM status: CCB request completed with an error (probe2:aacp2:0:0:0): Retrying command (probe2:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe2:aacp2:0:0:0): CAM status: CCB request completed with an error (probe2:aacp2:0:0:0): Error 5, Retries exhausted ses0 at aacp2 bus 0 scbus4 target 0 lun 0 ses0: AIC SES_BP-4D-1F 130a Fixed Enclosure Services SCSI-5 device ses0: 3.300MB/s transfers (8bit) ses0: SCSI-3 ENC Device regards, ___ 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: 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 and network virtualization
On Wed, Feb 5, 2014 at 12:59 PM, Kevin Bowling kevin.bowl...@kev009.comwrote: Has anyone used VALE with bhyve yet? It's in 10.0-RELEASE http://info.iet.unipi.it/~luigi/vale/ Just a general question on virtual network how encapsulatable (ability to wrap standardized wrappers around them) to do the different things... the reason for this is when I added the support for whatever networking solution(s) we choose I want to add them in the same way we did hypervisors (a stripped down plugin model [which will be expanded in future versions to be more complete])... does anyone see any reason why this model could not be used? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ 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: CFT: Very rough draft of PetiteCloud 0.2.4 (Linux as a host)
On Wed, Feb 5, 2014 at 1:00 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, February 04, 2014 09:55:13 AM Michael Dexter wrote: May I suggest you take this all to a personal blog? I agree. You can use a blog on petitecloud.org if you wish, but the purpose of this list is discussing virtualization techniques FreeBSD supports including jails/vimage, hypervisors (bhyve), and accelerated guest support (e.g. Xen HVM and Hyper-V drivers). An occasional note about petitecloud may be warranted, but the current volume is excessive. Also, this list is not suitable for use as a support forum for a commercial product. It is certainly appropriate for bug reports in the aforementioned list of topics (e.g. bhyve bugs or bhyve performance testing results) that may come out of downstream bug reports. 1. We'll be creating our own mailing list as soon as we can solve these technical issues: a. Mailman (under apache22) seems to insist on being on port 80. We have no machine that is on the public internet that has 80 not used by tomcat. Any ideas on how to fix this? (Both machines are at RootBSD and have 9.2-RELEASE on them.) b. The way our internal build system works, updating petitecloud.org also triggers a snapshot release of PetiteCloud and it is currently in a state that is not releasable (massive security issues on the Linux end [FreeBSD has no such issues]) 2. You seem to be under the impression that PetiteCloud is a commercial product. It is in fact 100% Free Open Source (BSD license) and Open Knowledge. We do plan to sell products that are ENABLED by PetiteCloud but are NOT REQUIRED by PetiteCloud in any way. (Thus there will be no enterprise edition, secret sauce, high-priced training, etc.) Also we eventually plan, once there is enough interest, to form a foundation on the FreeBSD/Apache model and transfer PetiteCloud completely over to it. The reason for this is that we do not see any honest way to make money from PetiteCloud itself, but only from various types of products it enables. We will also encourage anyone who wants to build products or open source (also hopefully open knowledge) projects on top of PetiteCloud (even if they are direct competitors of our commerical products) 3. Yes the comments on why we now have support for a non-FreeBSD host (as well as for FreeBSD, our preferred OS) really belong on a different forum. Since we have not yet created said forum, for the temporary technical reasons mentioned above, -virtualization@ seemed the only appropriate place to post our announcement, since the actual announcement was only a CFT and 100% of our users are FreeBSD. 4. Currently the only available place to discuss cloud computing at all on FreeBSD is -virtualization@. A -cloud@ list might make more sense if there was one. We would strongly urge the creation of such a list, because we consider FreeBSD to be, without question, the best operating system for truly stable and robust cloud computing, and we would strongly encourage the FreeBSD Foundation to emphasize this in its advocacy. In the meantime, please note that PetiteCloud is not yet a full-fledged cloud platform, but currently is little more than just a front end for various hypervisors including bhyve (our preferred hypervisor 5.. We would appreciate clarification on what kinds of announcements are appropriate here. For example, we've been posting calls for testing of new versions of PetiteCloud for almost five months with no objection from anyone (except for an early question from Michael Dexter about how truly open-source we were) until we added support for a non-FreeBSD host. May we continue to post CFT's that contain FreeBSD-related issues (including making sure we didn't break anything related to our FreeBSD support when adding features required by other OS's). 6. Since we purposely do not collect user email addresses at any point in the download and/or install, we will have no other quick way, besides -virtualization@ itself, to tell users where to ask questions about PetiteCloud now that -virtualization@ is no longer the correct place to send things. Thus we will need to make at least one more purely administrative/support oriented post before the move is complete 7. Miscellaneous a. We will sending the $50 we had offered to give someone on -emulation@ to the FreeBSD foundation, earmarked for work on virtualization and cloud computing. (The person to whom we offered the $50, for a solution to a problem we had been struggling with, told us to keep it.) b. As soon the appropriate person at the FreeBSD foundation contacts us, we will arrange to transfer freebsd-openstack.org to the foundation, if the FreeBSD foundation desires to be in charge of such a portal. We do want to keep editorial control until we can put a basic content management system in place and populate it with some initial content. -- Aryeh M. Friedman,
