In the vain hope this'll help others having this issue...
Having looked at this now for some time - and run a lot of tests, the
current best solution to allow a FreeBSD domU under XenServer 6.5 to act as
a gateway, or run OpenVPN (or dhcpd etc.) and remain agile - is to switch
to VirtIO NIC's.
em1000 (em) causes migrations to fail at the destination end.
Realtek (re) causes 'watchdog errors' - and if you get rid of the
watchdog code from the driver, you don't see the errors - but the NIC's
won't pass traffic after a migrate either.
PV (xn) have the original problem of not being able to provide routed
traffic from one FreeBSD domU to other domU guests, don't work with OpenVPN
(apparent 'packet size issues' from packet collation), and don't work for
virtio (vtnet) Work for routing for other domU's, work for OpenVPN, work
for dhcpd. The *only* disadvantage [aside from possibly performance] I've
found is that if you migrate a PV (xn) based FreeBSD domU you suffer around
2-3 seconds of network disconnect.
With a VirtIO (vtnet) interface this can be as high as 18 seconds of
network disconnect when you migrate. This means there's more of a chance of
disrupting sessions that were active either on, or through the DomU. But it
So until netfront is fixed (where we can hopefully go back to the
undoubtedly more efficient PV 'xn' NIC's) - this is the best workaround for
us - to use virtio (vtnet).
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"