Bugzilla – Bug 509
Changes needed to support dom0 in Indiana
Last modified: 2009-10-14 23:14:56 UTC
You need to log in before you can comment on or make changes to this bug.
I was unable to install any xVM domU's on preview 2 (after adding all of the necessary packages, of course). Every attempt would fail with the following in /var/log/xen/xend.log: [2008-02-10 12:52:26 xend 3669] DEBUG (XendDomain:431) Adding Domain: 23 [2008-02-10 12:52:26 xend 3669] DEBUG (DevController:149) Waiting for devices vif. [2008-02-10 12:52:26 xend.XendDomainInfo 3669] DEBUG (XendDomainInfo:824) XendDomainInfo.handleShutdownWatch [2008-02-10 12:52:26 xend 3669] DEBUG (DevController:154) Waiting for 0. [2008-02-10 12:52:26 xend 3669] DEBUG (DevController:561) hotplugStatusCallback /local/domain/0/backend/vif/23/0/hotplug-status. [2008-02-10 12:54:06 xend 3669] DEBUG (DevController:549) destroyCallback /local/domain/23/device/vif/0. [2008-02-10 12:54:16 xend 3669] ERROR (SrvBase:88) Request wait_for_devices failed. Traceback (most recent call last): File "/usr/lib/python2.4/vendor-packages/xen/web/SrvBase.py", line 85, in perform return op_method(op, req) File "/usr/lib/python2.4/vendor-packages/xen/xend/server/SrvDomain.py", line 85, in op_wait_for_devices return self.dom.waitForDevices() File "/usr/lib/python2.4/vendor-packages/xen/xend/XendDomainInfo.py", line 518, in waitForDevices self.getDeviceController(devclass).waitForDevices() File "/usr/lib/python2.4/vendor-packages/xen/xend/server/DevController.py", line 150, in waitForDevices return map(self.waitForDevice, self.deviceIDs()) File "/usr/lib/python2.4/vendor-packages/xen/xend/server/DevController.py", line 159, in waitForDevice self.destroyDevice(devid, False) File "/usr/lib/python2.4/vendor-packages/xen/xend/server/DevController.py", line 237, in destroyDevice raise EnvironmentError EnvironmentError [2008-02-10 12:54:16 xend.XendDomainInfo 3669] DEBUG (XendDomainInfo:1519) XendDomainInfo.destroy: domid=23 [2008-02-10 12:54:16 xend.XendDomainInfo 3669] DEBUG (XendDomainInfo:1527) XendDomainInfo.destroyDomain(23) [2008-02-10 12:54:17 xend 3669] DEBUG (DevController:549) destroyCallback /local/domain/23/device/vif/0. [2008-02-10 12:54:17 xend 3669] DEBUG (DevController:557) destroyCallback /local/domain/23/device/vif/0 is destroyed With assistance from the xVM community, we discovered that the sysevent registrations that xVM is relying on are not included, because they're done in the postinstall script of SUNWxvmdomu. We likely need to add a sysevent action to handle these registrations. The workaround is to run the following after all the xVM packages are installed: syseventadm add -c EC_xendev \ /usr/lib/xen/scripts/xpvd-event 'action=$subclass' \ 'domain=$domain' 'vdev=$vdev' 'device=$device' \ 'devclass=$devclass' 'febe=$fob' syseventadm add -c EC_xpvsys \ /usr/lib/xen/scripts/xpvsys-event 'subclass=$subclass' \ 'shutdown=$shutdown'
We could do this as a dedicated action (syseventadm has a -R option), but, if this registration isn't needed for system boot, we could also handle it via the coalescing idea for "postaction".
I spoke with John Levon about this recently and either using Stephen's "postaction" consumer or perhaps folding this into one of existing relevant xVM services as a part of the start method seem to be viable solutions.
Fixed Assignee.
...and the QA Contact.
*** Bug 1693 has been marked as a duplicate of this bug. ***
comment #2: actually, I don't see how this would work, as we also need to remove the actions if the packages are removed. Nor can we just drop files into /etc/sysevent/config/, since we have no way to signal syseventd. A proper sysevent action is the only solution I can see here that works properly.
Actually, you'll be able to restart or refresh any service on file addition or removal.
So we need to make /etc/sysevent/config/ a Stable interface instead of the current private one, and wait for the ability to nudge FMRIs on a file action, right?
The issue with syseventadm should be resolved now. Keeping this open to cover the addition of the xVM entries to menu.lst and the need to enable the xVM services by hand.
*** Bug 4765 has been marked as a duplicate of this bug. ***
Fixed by 6885672, in b126