On Wed, Oct 9, 2013, at 2:46, Roger Pau Monné wrote:
> On 09/10/13 08:18, Shanker Balan wrote:
> > On 08-Oct-2013, at 9:19 PM, Mark Felder <f...@freebsd.org> wrote:
> > 
> >> 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: 
> >>> run_interrupt_driven_hooks - still waiting after 300 seconds for
> >>> xenbusb_nop_confighook_cb
> >>> panic: run_interrupt_driven_config_hooks: waited too long
> >>>
> >>
> >> I was going to test this soon... but you're right -- you probably can't
> >> install FreeBSD 10 from ISO on Citrix XenServer because of this bug.
> >>
> >> Can someone working on the xen bits test and maybe find a workaround?
> > 
> > The "xenbusb_nop_confighook_cb" issue is the only issue which I am aware
> > of that prevents CloudStack/XenServer IaaS private clouds from offering
> > FreeBSD 10 as a supported OS template. The "vbd-destroy" workaround is not
> > possible as the ISO is attached to the VM instance during the installation.
> > 
> > A "please pretty please" request to @citrix R&D for the hopefully last fix
> > to get FreeBSD 10 running on XenServer+CloudStack.
> > 
> > The earlier HyperV related panic on XenServer has been fixed in ALPHA5.
> Hello,
> 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 are
> disconnected, and there's no fine grained way to only disable IDE disks
> and not cdrom devices.
> Could you please contact your XenServer representative, and/or submit
> this bug to xs-devel (xs-de...@lists.xenserver.org) mailing lists in
> order to get this fixed on XenServer.

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. 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 release is
supposed to merge with upstream qemu.

But the fact remains that this is a non-issue on Linux and NetBSD who
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-box
support on the premier commercial Xen platform we'll be shooting
ourselves in the foot and all of this work will be for naught. Amazon
isn't the only Xen platform people use.
freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to