From owner-freebsd-xen@FreeBSD.ORG Sun Oct 13 14:58:44 2013 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63E1C559 for ; Sun, 13 Oct 2013 14:58:44 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3098226C4 for ; Sun, 13 Oct 2013 14:58:43 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B28F12112F for ; Sun, 13 Oct 2013 10:58:42 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Sun, 13 Oct 2013 10:58:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=6GbpC5RwhpbLNQUdQb8V4vnhdOA=; b=hgI ZARRbWJ3kqCMnGuNHgPE3x8XN1GvAKXIGUHmMfYMBXsU/2TUE9PBVIlVZbndstiT PSooQ27zpAXskNW1Ct+OiSut5aR33yWqNpUsbecrnEOrtaoTJSMaqjinuzqSRqXF aCPSeVQIR/MrfCwHWUE8/7AycZGRc3ZtZK7/mNAc= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 89D5D119632; Sun, 13 Oct 2013 10:58:42 -0400 (EDT) Message-Id: <1381676322.11187.33436965.1BBB5473@webmail.messagingengine.com> X-Sasl-Enc: E1kGC6Jc6KyRS8zC2kMHVdPOkAdgTe8JkFiDLS6llz/t 1381676322 From: Mark Felder To: freebsd-xen@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: References: <1381247394.22461.31501241.11EE316E@webmail.messagingengine.com> <8F3E4CEF-75BB-4F96-8512-87B21C5AC44E@shankerbalan.net> <525509C4.9010407@citrix.com> <1381319360.6600.31880785.6E83A2F9@webmail.messagingengine.com> <52555FF4.8010107@citrix.com> <1381329411.11572.31947565.7C2A280B@webmail.messagingengine.com> <849AB77F-D2E3-4BFB-B957-F9A9E53D1070@shankerbalan.net> <7B7BC687-3A64-4B3D-9F90-B73FC6938225@shankerbalan.net> Subject: Re: FreeBSD Alpha5 amd64 - Citrix Xen 6.2 problem Date: Sun, 13 Oct 2013 09:58:42 -0500 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 13 Oct 2013 14:58:44 -0000 On Sat, Oct 12, 2013, at 21:48, Justin T. Gibbs wrote: > On Oct 10, 2013, at 3:09 AM, Shanker Balan wrote: >=20 > >=20 > > On 10-Oct-2013, at 1:37 PM, Shanker Balan wrote: > >=20 > >> On 09-Oct-2013, at 8:06 PM, Mark Felder wrote: > >>=20 > >>> On Wed, Oct 9, 2013, at 8:53, Roger Pau Monn=E9 wrote: > >>>> On 09/10/13 13:49, Mark Felder wrote: > >>>>> On Wed, Oct 9, 2013, at 2:46, Roger Pau Monn=E9 wrote: > >>>>>> On 09/10/13 08:18, Shanker Balan wrote: > >>>>>>> On 08-Oct-2013, at 9:19 PM, Mark Felder wrote: > >>>>>>>=20 > >>>>>>>> On Tue, Oct 8, 2013, at 9:45, Josias L.G wrote: > >>>>>>>>> Problem with Citrix Xen 6.2 and install from ISO. The "solution= " was > >>>>>>>>> remove cd-rom drive from virtual machine. Not possible now with= xen > >>>>>>>>> default in GENERIC kernel. > >>>>>>>>> Message error:=20 > >>>>>>>>> run_interrupt_driven_hooks - still waiting after 300 seconds for > >>>>>>>>> xenbusb_nop_confighook_cb > >>>>>>>>> panic: run_interrupt_driven_config_hooks: waited too long > >>>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> I was going to test this soon... but you're right -- you probabl= y can't > >>>>>>>> install FreeBSD 10 from ISO on Citrix XenServer because of this = bug. > >>>>>>>>=20 > >>>>>>>> Can someone working on the xen bits test and maybe find a workar= ound? > >>>>>>>=20 > >>>>>>> The "xenbusb_nop_confighook_cb" issue is the only issue which I a= m aware > >>>>>>> of that prevents CloudStack/XenServer IaaS private clouds from of= fering > >>>>>>> FreeBSD 10 as a supported OS template. The "vbd-destroy" workarou= nd is not > >>>>>>> possible as the ISO is attached to the VM instance during the ins= tallation. > >>>>>>>=20 > >>>>>>> A "please pretty please" request to @citrix R&D for the hopefully= last fix > >>>>>>> to get FreeBSD 10 running on XenServer+CloudStack. > >>>>>>>=20 > >>>>>>> The earlier HyperV related panic on XenServer has been fixed in A= LPHA5. > >>>>>>=20 > >>>>>> Hello, > >>>>>>=20 > >>>>>> I've taken a look into this and I'm afraid there's no easy way to > >>>>>> workaround it from FreeBSD. When Xen is detected all IDE devices a= re > >>>>>> disconnected, and there's no fine grained way to only disable IDE = disks > >>>>>> and not cdrom devices. > >>>>>>=20 > >>>>>> Could you please contact your XenServer representative, and/or sub= mit > >>>>>> this bug to xs-devel (xs-devel@lists.xenserver.org) mailing lists = in > >>>>>> order to get this fixed on XenServer. > >>>>>>=20 > >>>>>=20 > >>>>> Citrix is aware of this as I've contacted several people there and = this > >>>>> has been discussed both here and on the xs-devel list. There has to= be > >>>>> something FreeBSD can do to work around this issue since Linux and > >>>>> NetBSD have no issues. > >>>>=20 > >>>> Linux and NetBSD have no issues because you probably only tried them= on > >>>> PV mode, which doesn't exhibit this issue (also NetBSD doesn't have > >>>> PVHVM support, so it's quite clear it won't have this issue). > >>>>=20 > >>>>> As far as I'm aware the issue has been tracked > >>>>> down to badly behaving qemu in XenServer -- they don't use upstream= qemu > >>>>> in XenServer (yet), and instead have their own fork. A future relea= se is > >>>>> supposed to merge with upstream qemu. > >>>>=20 > >>>> The main problem here is that XenServer announces a PV block device = on > >>>> xenstore (the cdrom), but then it seems like there's no backend to > >>>> handle it, so it hangs on the connection phase. IMHO the problem is = not > >>>> with the device model (Qemu), but with the backend that should handle > >>>> this PV device. > >>>>=20 > >>>> Xen only allows you to either disable all IDE devices or none, so the > >>>> only possible solution I can think of is to not disable anything at = all > >>>> and use the emulated devices, which will leave us with very poor > >>>> performance (unless I'm missing something, there's no way to only > >>>> disable disks but not cdroms). > >>>>=20 > >>>>> But the fact remains that this is a non-issue on Linux and NetBSD w= ho > >>>>> handle this buggy virtual CDROM without any problems. There has to = be > >>>>> some way we can add a quirk on our side so this device doesn't stop= the > >>>>> entire boot process. If FreeBSD 10 is released without out-of-the-b= ox > >>>>> support on the premier commercial Xen platform we'll be shooting > >>>>> ourselves in the foot and all of this work will be for naught. Amaz= on > >>>>> isn't the only Xen platform people use. > >>>>=20 > >>>> You can always use the pre-build VM images I guess (I have not tested > >>>> those, but I expect they should work fine under Xen). > >>>>=20 > >>>> ftp://ftp.nl.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/20131007/10= .0-ALPHA5/amd64/ > >>>>=20 > >>=20 > >> This is way better. Having ready to import Xen images beats ISO instal= lation > >> any day. Will try on my cloudstack setup later today. > >=20 > > I converted the QCOV image to VHD and have imported it into CloudStack.= Instance > > created from the template also have the "xenbusb" issue at bootup. > >=20 > > Oh well. > >=20 > > Thanks for all the help. > >=20 > > Regards. > > @shankerbalan >=20 > The CDROM issue should be resolved in FreeBSD/head. These fixes will be > include > in 10.0-BETA2 as well as the first 11-CURRENT snapshot that should pop up > in > the next day or two. The snapshots are announced on the > freebsd-snapshots > mailing list. >=20 Can you please backport to 9-STABLE? This issue is what is preventing me from upgrading my Xen infrastructure at work. Thanks so much!