> On Feb 1, 2009, at 7:14 PM, Jonathan Wheeler wrote: > >> .... > > > >> From what I've seen to date, anyone that tries to use opensolaris > >> under VMware esx on 64-bit hardware (the majority now in 2009!), > >> will be unable to use crossbow. > > > > That's quite a biggie don't you agree? > > Jonathan, Hi Nicolas :)
> This is not a Crossbow issue. There isn't much we can > do from Crossbow > running in a guest if the packets are not even passed > up to the > emulated e1000g in that guest. I quite agree that this point is obviously beyond crossbow's control, though at the same time it should be understood that it's not really VMware's "fault" for locking down ports using mac level security either. In my searching to date the only other scenarios that typically runs into this problem are IDS/IPS appliances, so it's not very common out in the wild at all. The good news is that once an administrator *does* understand the nature of this problem, or perhaps more accurately "VMware ESX's default vSwitch behaviour", vSwitch security can quite easily be reconfigured to allow for the "crossbow-friendly" handling of promiscuous mode on the switch port for the guest. > VMware should allow > you you to pass > these unicast packets up to the VM And it can, you just have to *know* to enable the promiscuous port mode with port groups. > and put the > underlying physical NIC > in promiscuous mode. When using the e1000 nic, this one is the problematic bit. VMware ESX will allow a guest to put it's NIC into promiscuous mode as we've seen with my infamous "snoop test", which in turn behind the scenes sets the virtual port on the virtual switch to promiscuous mode too. This "opens the floodgates" so to speak, allowing crossbow to do it's work. This isn't an issue when using a 32-bit solaris guest, which use the pcn or vmxnic nics. I gather the explanation here is that crossbow is setting the promiscuous flag on the nic by default because these NICs don't support hardware unicast mac filters. > There no easy way to workaround this problem from the > guest beside > putting the virtual e1000g NIC in promiscuous mode, > using snoop for > example. For the long term we were planning to allow > a user to specify > from dladm(1M) that a VNIC should not be using a > hardware unicast > slot, which would as a side effect put the underlying > NIC in > promiscuous mode and help in your case. Yes, that would be one surefire way solve this problem. Wooho! Even better, if there was a way to detect that the solaris instance is running in a virtual environment, and therefore DON'T use a hardware unicast slot.... problem solved dynamically! I understand that this only helps to solve a problem with VMware ESX and not other virtualisation products such as Vbox, however are the alternate virtualisation platforms actually benefiting from using this NIC feature; they are only simulating virtual hardware unicast slots anyway, so they must not be hardware accelerated anyway? This logic/codepath probably isn't something for the crossbow team is it?... Would this be something more for the ON/e1000g driver developers to look into? I don't really know how or to whom I should be gently encouraging this RFE :) > For the short term you may want to try a different VM > host. For > example I've tried this from VirtualBox in the past > and it works fine > with an emulated e1000g. I agree that is problem is so far unique to VMware ESX, however that is what my production enviroment uses, so while it's great to have confirmed that this issue is only affecting VMware ESX.... well I, and any other future VMware ESX users, still need a workaround :) I'm hoping that this thread will provide a helpful reference for all future users (hi google!) that hit this same problem, but better yet, would it be possible to more formally document this now known limitation when using crossbow in a VMware ESX enviroment, on the official project page's Network Virtualization and Resource Control (Crossbow) FAQ? Jonathan > Nicolas. > > -- > Nicolas Droux - Solaris Kernel Networking - Sun > Microsystems, Inc. > droux at sun.com - http://blogs.sun.com/droux > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow- > discuss -- This message posted from opensolaris.org
