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
>>>>> 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.
>> 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).
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"