Can opensolaris domU act as block/network device backend?>From "xm create --help_config" I see that the option blkif and netif is there.-- Fajar
On 8 Sep 2009, at 7:22am, Fajar A. Nugraha wrote:> Can opensolaris domU act as block/network device backend? >> From "xm create --help_config" I see that the option blkif and >> netif is there.The xdb (simple disk) backend certainly used to work in a domU - it was used that way during its'' development. I don''t know much about the xpvtap backend. The network backend (xnb) has never, to my knowledge, been used in a domU. The VNIC approach would probably not work well there (VNICs created in a domU don''t generally get any traffic due to the switching that occurs in dom0).
On Tue, Sep 8, 2009 at 2:16 PM, David Edmondson<dme@sun.com> wrote:> On 8 Sep 2009, at 7:22am, Fajar A. Nugraha wrote: >> >> Can opensolaris domU act as block/network device backend?> The xdb (simple disk) backend certainly used to work in a domU - it was used > that way during its'' development.Any document/hints on how to use it? I got as far as seeing these messages on opensolaris domU Sep 10 06:20:54 os-pv xpvd: [ID 395608 kern.info] xenbus@0, xenbus0 Sep 10 06:20:54 os-pv genunix: [ID 936769 kern.info] xenbus0 is /xpvd/xenbus@0 Sep 10 06:21:44 os-pv xpvd: [ID 395608 kern.info] domcaps@0, domcaps0 Sep 10 06:21:44 os-pv genunix: [ID 936769 kern.info] domcaps0 is /xpvd/domcaps@0 Sep 10 06:23:44 os-pv genunix: [ID 408114 kern.info] /xpvd/xdb@0,51712 (xdb0) online Sep 10 06:24:21 os-pv emlxs: [ID 709872 kern.warning] WARNING: emlxs: ddi_modopen drv/fct failed: err 2 Sep 10 06:25:24 os-pv genunix: [ID 408114 kern.info] /xpvd/xdb@0,51712 (xdb0) offline Sep 10 06:28:41 os-pv genunix: [ID 408114 kern.info] /xpvd/xdb@0,51712 (xdb0) online Sep 10 06:29:40 os-pv genunix: [ID 408114 kern.info] /xpvd/xdb@0,51712 (xdb0) offline Sep 10 06:37:13 os-pv genunix: [ID 408114 kern.info] /xpvd/xdb@54,51728 (xdb1) online But "xm block-attach" on dom0 failed with Error: Device 51728 (vbd) could not be connected. Hotplug scripts not working. Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain] -- Fajar
On 10 Sep 2009, at 2:45am, Fajar A. Nugraha wrote:> Error: Device 51728 (vbd) could not be connected. Hotplug scripts > not working. > Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> > [BackDomain]What is the output of ''syseventadm list'' in the domU?
On Thu, Sep 10, 2009 at 10:02 PM, David Edmondson <dme@sun.com> wrote:> > On 10 Sep 2009, at 2:45am, Fajar A. Nugraha wrote: >> >> Error: Device 51728 (vbd) could not be connected. Hotplug scripts not >> working. >> Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain] > > What is the output of ''syseventadm list'' in the domU? > >So I try again with this command # xm block-attach osol2 phy:/dev/zvol/dsk/rpool/vbd/test1 xvdc w osol Error: Device 51744 (vbd) could not be connected. Hotplug scripts not working. Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain] Create a new virtual block device. The output of syseventadm list is the same in both backend and frontend (the one that gets the new block device) domU: # syseventadm list vendor=SUNW publisher=pcieb class=EC_dr subclass=ESC_dr_req /usr/lib/pci/pcidr class=$class subclass=$subclass publisher=$publisher dr_request_type=$dr_request_type dr_ap_id=$dr_ap_id vendor=SUNW publisher=pcieb_bcm class=EC_dr subclass=ESC_dr_req /usr/lib/pci/pcidr class=$class subclass=$subclass publisher=$publisher dr_request_type=$dr_request_type dr_ap_id=$dr_ap_id vendor=SUNW class=EC_dev_status subclass=ESC_dev_dle /usr/lib/fs/zfs/zfsdle $phys_path When I execute the block-attach, the frontend domU got these on /var/adm/messages: Sep 11 14:40:22 os-pv xpvd: [ID 395608 kern.info] xdf@51744, xdf2 Sep 11 14:40:22 os-pv genunix: [ID 936769 kern.info] xdf2 is /xpvd/xdf@51744 Sep 11 14:40:22 os-pv genunix: [ID 408114 kern.info] /xpvd/xdf@51744 (xdf2) online Sep 11 14:40:22 os-pv xpvd: [ID 395608 kern.info] domcaps@0, domcaps0 Sep 11 14:40:22 os-pv genunix: [ID 936769 kern.info] domcaps0 is /xpvd/domcaps@0 and format shows this AVAILABLE DISK SELECTIONS: 0. c7t0d0 <DEFAULT cyl 3915 alt 0 hd 255 sec 63> /xpvd/xdf@51712 1. c7t2d0 <drive type unknown> /xpvd/xdf@51744 c7t2d0 is the new drive. Selecting "1" hangs until I press ctrl-C though, so I guess something is still wrong. Both frontend and backend domU are opensolaris snv_122, dom0 is RHEL running Xen 3.4.1. Perhaps the dom0 matters? WIll using opensolaris dom0 make this work? -- Fajar
On 11 Sep 2009, at 8:44am, Fajar A. Nugraha wrote:> The output of syseventadm list is the same in both backend and > frontend (the one that gets the new block device) domU: > > # syseventadm list > vendor=SUNW publisher=pcieb class=EC_dr subclass=ESC_dr_req > /usr/lib/pci/pcidr class=$class subclass=$subclass > publisher=$publisher dr_request_type=$dr_request_type > dr_ap_id=$dr_ap_id > vendor=SUNW publisher=pcieb_bcm class=EC_dr subclass=ESC_dr_req > /usr/lib/pci/pcidr class=$class subclass=$subclass > publisher=$publisher dr_request_type=$dr_request_type > dr_ap_id=$dr_ap_id > vendor=SUNW class=EC_dev_status subclass=ESC_dev_dle > /usr/lib/fs/zfs/zfsdle $phys_pathThis isn''t enough for the the guest to provide backend services - there should be something for EC_xpvdev or EC_xendev, depending on the age of your bits. I''d guess that the packaging re-vamp means that the sysevent script isn''t being added by the SMF service for a guest domain. johnlev - what did you decide about this?
On Tue, Sep 15, 2009 at 09:11:21AM +0100, David Edmondson wrote:> I''d guess that the packaging re-vamp means that the sysevent script > isn''t being added by the SMF service for a guest domain.Ah, yeah, xenstore won''t start up, so you won''t get the service added. There''s also packaging problems (you can''t just install SUNWxvmdom like you''re supposed to be able to).> what did you decide about this?Quite honestly, nobody is ever testing this, I''d be amazed if it still worked. regards john