On Sat, Oct 12, 2013, at 21:48, Justin T. Gibbs wrote: > On Oct 10, 2013, at 3:09 AM, Shanker Balan <m...@shankerbalan.net> wrote: > > > > > On 10-Oct-2013, at 1:37 PM, Shanker Balan <m...@shankerbalan.net> wrote: > > > >> On 09-Oct-2013, at 8:06 PM, Mark Felder <f...@freebsd.org> wrote: > >> > >>> On Wed, Oct 9, 2013, at 8:53, Roger Pau Monné wrote: > >>>> On 09/10/13 13:49, Mark Felder wrote: > >>>>> 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. > >>>> > >>>> 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). > >>>> > >>>>> 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. > >>>> > >>>> 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. > >>>> > >>>> 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). > >>>> > >>>>> 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. > >>>> > >>>> 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). > >>>> > >>>> ftp://ftp.nl.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/20131007/10.0-ALPHA5/amd64/ > >>>> > >> > >> This is way better. Having ready to import Xen images beats ISO > >> installation > >> any day. Will try on my cloudstack setup later today. > > > > 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. > > > > Oh well. > > > > Thanks for all the help. > > > > Regards. > > @shankerbalan > > 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. >
Can you please backport to 9-STABLE? This issue is what is preventing me from upgrading my Xen infrastructure at work. Thanks so much! _______________________________________________ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
