|
xen-devel
[Xen-devel] Re: Back end domains : input desired
> DOM0: minimal linux install with LVM2 primarily for backending the ide
> disks.
Fine.
> BE_NIC_0: Back end NIC_0 domain (bridge) with minimal linux install -
> no ip address assigned - using ebtables to filter/protect
> BE_NIC_1: Same as BE_NIC_0 only for NIC_1
This should work, although a recent post suggested there was some sort of bug
in the multiple backend support...
> BE_VNIC_2: Back end for a "virtual nic"/bridge for DomU to DomU
> communication (DMZ).
So does this have any connections to the physical network cards at all?
The problem is that AFAIK the current code won't allow a domain to run a
backend driver unless it's controlling a real physical device.
> BE_MGMT: firewall config/mgmt console (xwindows) (preferred x
> displaying (direct) through AGP on console - is this possible) and
> ntp/clock sync (can this happen here or does it have to happen on
> DOM0?).
Clock sync can probably only occur from dom0 at the moment. Likewise for AGP
access (although one user had some success in giving a graphics card to a
domU, it's not fully working yet).
> Various front end DomU's: for router/fw and various application layer
> gateways.
Right.
> My idea here is to be able to isolate the components into minimal
> operating environments allowing for specific need/application to be
> rebooted without having to reboot the entire box should that particular
> component be DoS'ed.
Makes sense.
> 1) I only seem to be able to compile the actual NIC drivers with DOM0
> (e100/e1000/3c95x, etc). Is this where I should be compiling them even
> though the NIC's will be used in another DOM? If not, how do I go about
> compiling the drivers for the BE DOM'S? (they don't show up as options -
> yes, I do have XEN_PHYSDEV_ACCESS and XEN_NETDEV_BACKEND enabled.
Just stick all the drivers you need into a xen0 kernel, then use that kernel
in any domain that's talking to the hardware. You can use a xen0 kernel
anywhere.
> 2) Even with pci_dom0_hide=(01,01,0)(02,00,0) as part of my grub.conf
> (for the startup of xen.gz), I still see these devices under DOM0, is
> this normal? lspci shows the devices as 0000:01:01.0 and 0000:02:00:0.0)
> respectively. Are my parameters to pci_dom0_hide correct?
Try physdev_dom0_hide - pci_dom0_hide is a bug that got introduced to the docs
at some point (I think it has now been fixed).
> 3) Should I be using stable, testing or unstable for this? NOTE:
> stable and testing both are unable to attach xen console to ttyS whereas
> unstable works correctly for this.
In general, use stable for production environments. Testing is the "next
stable release" and so is quite stable itself (and may have additional bug
fixes).
> 4) It would be preferred to run X in a domain separate from Dom0, but
> still be accessible for use on the local console without having to
> install X and a VNC client in DOM0. Is this possible, or am I just
> dreaming here?
Possible in theory, in practice this doesn't quite work yet.
HTH,
Mark
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
Home