Re: bhyve code question, pci_virtio_net.c

2015-05-16 Thread John-Mark Gurney 
Allan Jude wrote this message on Sat, May 16, 2015 at 13:02 -0400:
 While looking at the code, I noticed the following comment:
 
   /*
* 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
*/
   if (!mac_provided) {
   snprintf(nstr, sizeof(nstr), %d-%d-%s, pi-pi_slot,
   pi-pi_func, vmname);
 
 
 which raised 2 questions:
 1) According to the comment, the mac address should be based on the md5
 of the DEVICE name, not the VM name. Which is correct? Which is more
 desirable?
 
 I suppose most people's VMs will have similar slot/func numbers for the
 NIC (especially with certain config engines that always assign devices
 in a specific order), and so the VM name is more likely to be unique
 than the name of the tap device.

Correct, VM name makes the most sense here...

 Would it make sense to include more unique information in this hash?
 like the host's UUID or something, to prevent the chance of more than 1
 VM on the same LAN having the same MAC if they have the same VM Name?

Sure...

 2) Should bhyve instead use the FreeBSD assigned OUI for these MAC
 addresses?

Depends, if NetApp gave us permission to use them here, then we might
as well keep using them.  gnn would be the persion to talk to about
this..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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

[Differential] [Commented On] D1944: PF and VIMAGE fixes

2015-05-16 Thread nvass-gmx.com (Nikos Vassiliadis) 
nvass-gmx.com added a comment.

In https://reviews.freebsd.org/D1944#47231, @rodrigc wrote:

 I tested this patch.

   # kldload pf
   # kldunload pf
   kldunload: can't unload file: Device busy


 The fact that the pf module cannot be unloaded was one of the
  reasons that @glebius used to back out the entire changeset last time
  I committed your pf changes.  Can you fix this?


This is intended behaviour, regadless of VIMAGE. You need to use kldunload -f
to unload it.

 I also saw this in dmesg:

 

   CURVNET_SET() recursion in pfi_vnet_initialize() line 130, prev in 
 vnet_register_sysinit()

   0xf800056e4100 - 0xf800056e4100

   KDB: stack backtrace:

   db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
 0xfe046389a550

   pfi_vnet_initialize() at pfi_vnet_initialize+0x21b/frame 0xfe046389a590

   pf_vnet_init() at pf_vnet_init+0x35/frame 0xfe046389a5c0

   vnet_register_sysinit() at vnet_register_sysinit+0x13c/frame 
 0xfe046389a600

   linker_load_module() at linker_load_module+0xc87/frame 0xfe046389a920

   kern_kldload() at kern_kldload+0x10e/frame 0xfe046389a970

   sys_kldload() at sys_kldload+0x5b/frame 0xfe046389a9a0

   amd64_syscall() at amd64_syscall+0x27f/frame 0xfe046389aab0

   Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046389aab0

 


This should be ok. It is just a warning that we are setting curvnet although
it is already set. Maybe it can be avoided.


REVISION DETAIL
  https://reviews.freebsd.org/D1944

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn
Cc: julian, robak, freebsd-virtualization, freebsd-pf, freebsd-net
___
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: adding vtnet to bridge results to kernel panic

2015-05-16 Thread Nikos Vassiliadis 

On 05/14/15 22:49, Peter Grehan wrote:

Hi Nikos,


Hi Peter,


I get this panic when I add vtnet0 to a bridge.


  I created a PR for this
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200210) and will look
into it.


Thanks


 Thanks in advance for any ideas,

  tap will work, though, I suspect you're using vtnet to retain a
config'd IP address when the guest exits ??


I don't have a specific use case. I was trying something (*) and I got
this panic and I reported it;)

*:
I was testing a big STP experiment with VIMAGE and I wanted to
connect the host to the experiment and I got this panic. After
that I tried to narrow down the panic's trigger, so I removed
VIMAGE and tried to connect vtnet to a bridge.

Thanks,
Nikos
___
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