From owner-freebsd-xen@FreeBSD.ORG Fri Sep 12 15:02:09 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C685E63B; Fri, 12 Sep 2014 15:02:09 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6646BC18; Fri, 12 Sep 2014 15:02:08 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s8CF27xG088877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 16:02:07 +0100 (BST) Date: Fri, 12 Sep 2014 16:02:07 +0100 From: Karl Pielorz To: Mark Felder , freebsd-xen@freebsd.org Subject: Re: Routing/NAT problem on Xenserver 6.2 with virtual firewall Message-ID: In-Reply-To: <1410529669.1815882.166744545.1E24373F@webmail.messagingengine.com> References: <86k359p1qm.fsf@arch.perpetuum.hr> <9864A2A7BE97EB706ED0FC04@Mail-PC.tdx.co.uk> <1410529669.1815882.166744545.1E24373F@webmail.messagingengine.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:02:09 -0000 --On 12 September 2014 08:47 -0500 Mark Felder wrote: > I'm confident you could patch out the HVM xn0 but keep the rest of the > HVM code so you have fast disk, etc, and you can run the xen tools which > then allows you to use XM and XSM :-) I know Roger has given me a patch > that does this while we were troubleshooting a performance issue. I did ask about that at the time - but it wasn't apparently viable (or easy? - it was a while back!)... It'd be a handy stopgap if it can be done. You suddenly realise how handy migration / motion is - when you can't have it! Our current solution is to have a separate 'HVM' only pool - where all the routing, vpn'ing, firewalling and dhcp FreeBSD VM's hang out. Even with just that workaround we could get rid of that pool, and get our agility back for those VM's... -Karl