Thanks for that Terence - I now have a better understanding and also a better
idea on what I want to do with regards to splitting the buses on my T5240.
However I'm not sure if it would benefit me to do this. Let me explain and let
me know what you think, your feedback what be most appreciated:-
In a previous LDOM config on a T5240 there was only a primary (control) domain
doing all the IO , servicing etc. points to note:-
--> T5240 installed via jumpstart onto local disks.
--> Primary domain set up with one virtual switch and 2 virtual disk services.
One disk service for the LUN's allocated for the Guest domains OS
One disk service for the LUN's for Guest domains application data
The PCI express HBA cards were put in PCI slots 4 and 5 ( p...@500) so that
they were not on the same bus as the internal disks ( p...@400). However the
internal quad network card is on p...@500
--> Guest domains were all jumpstarted onto the LUN's from vds 1 and then
application data LUN's allocated via vds 2.
Now I now have another T5240 that I have just installed the OS on and have been
exploring the possibility of creating a seperate IO domain hence all the
questions I have been asking
The way I see it on a T5240 is that the internal disks and the network devices
are on seperate buses. Ideally I would like them on the same bus freeing up the
other bus for an IO domain connected to the SAN storage.
The only way I see this happening is to get an PCI express 1GB NIC and install
it in slot 2 for example so that network and internal disks are on the same bus.
However the company does not want to spend money so I was thinking about still
splitting the buses having the internal disk on one bus and the network and SAN
storage on another bus ( IO domain ). To the IO domain I can add a virtual
switch for the guest domains to connect to.
I'm still not sure exactly what I'm trying to do here and maybe my prose is a
bit confusing but I would appreciate any feedback you may have to offer.
> On 06/08/2010 05:13, Ken Woolard wrote:
> > I'm slightly confused reading about setting up an
> IO Domain on a
> > T5240.
> >
> > I know how to set it up grabbing one of the 2 buses
> via ldm add-io
> > and I can also install an OS on it using the the
> VDS on the primary
> > domain.
> >
> > What confuses me is the next stage when I go to
> create a Guest
> > domain. Which commands are required when creating
> the Guest domain so
> > that it can access the storage via the IO Domain.
> >
> > It's the relationship between the IO domain and the
> Guest domain that
> > I want to understand
>
>
> Hi Ken
>
> A second I/O domain is usually created to provide
> guests an independent
> route to I/O from the primary domain.
>
> It also usually means that the second I/O domain
> itself is independent
> from the primary domain, otherwise a failure of the
> primary would also
> cause a failure in the second I/O domain.
>
> What you have described above is perfectly valid, but
> does not provide
> redundancy in case the primary domain fails, as the
> boot disk for the
> second I/O domain is provided by the primary domain (
> via the primary's
> VDS service).
>
> What we would normally expect is the second I/O to
> have its own boot
> disks that are on the PCI bus that you are assigning
> to the second I/O
> domain. In this case the disks will be external to
> the T5240.
>
> If, however, you are happy with the above arrangement
> of the primary
> supplying the disk to the second I/O domain you would
> need to create
> services in the second i/O domain in order for the
> guests to use those.
> You mention storage, so in that case you would create
> ( from the primary
> domain ) a vds service in the second I/O domain
>
> primary domain # ldm add-vds <new-service-name>
> <second I/O domain name>
>
> If you also have network also add a network service.
>
> Then you can add devices to the vds service and
> export those to the guests.
>
> Note that all of these commands are run from the
> primary domain as that
> is where the SUNWldm package is installed.
>
> T
> _______________________________________________
> ldoms-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/ldoms-dis
> cuss
>
--
This message posted from opensolaris.org
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
