Would anyone happen to have an pre installed image of the lustre ''stack'' available ? Robert.
Hi Robert, You''re likely to find that performance will suffer when run under a VM. Lustre makes pretty extensive use of all the resources at its disposal, and having to compete with physical devices under a VM that runs as an ordinary user process is more than likely going to lead to resource deadlocks. I wouldn''t suggest running Lustre under VMs. cheers, Klaus On 8/15/08 1:16 PM, "Robert Gordon" <rbg at openrbg.com>did etch on stone tablets:> > Would anyone happen to have an pre installed image of the lustre > ''stack'' available ? > > Robert. > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss
There seem to be a couple of assumptions here that would be worth examining further. My first thought is that running Lustre under something like Xen might be very usefull for virtualization, failover, and load balancing. If there is some potential resource deadlock that could occur, there ought to be some diagram or documentation of what deadlocks are possible. It would be a lot of work to conclusively figure out what the potential deadlocks actually are.. But it seems like a worthwhile excercise, and running Lustre in a VM would be a good way to do QA testing so that new deadlocks are not added by code changes. On Fri, Aug 15, 2008 at 03:17:39PM -0700, Klaus Steden wrote:> > Hi Robert, > > You''re likely to find that performance will suffer when run under a VM. > Lustre makes pretty extensive use of all the resources at its disposal, and > having to compete with physical devices under a VM that runs as an ordinary > user process is more than likely going to lead to resource deadlocks. > > I wouldn''t suggest running Lustre under VMs. > > cheers, > Klaus >
On Aug 17, 2008 09:08 -0500, Troy Benjegerdes wrote:> There seem to be a couple of assumptions here that would be worth > examining further. > > My first thought is that running Lustre under something like Xen might > be very usefull for virtualization, failover, and load balancing. > > If there is some potential resource deadlock that could occur, there ought > to be some diagram or documentation of what deadlocks are possible. It > would be a lot of work to conclusively figure out what the potential > deadlocks actually are.. But it seems like a worthwhile excercise, and > running Lustre in a VM would be a good way to do QA testing so that new > deadlocks are not added by code changes.If you are talking about running Lustre clients to host a distributed filesystem for many VMs then I think that is reasonable. Running many VMs on the same system, both client and server is quite pointless - you may as well just use a local filesystem or similar. There is definitely a known deadlock with a client and OST on the same node, when the client is trying to free memory, writes dirty data to Lustre, and then the local OST needs to allocate something to complete the IO where the VM blocks waiting for the client to write out its data... I don''t know if this would happen with two VMs however.> On Fri, Aug 15, 2008 at 03:17:39PM -0700, Klaus Steden wrote: > > You''re likely to find that performance will suffer when run under a VM. > > Lustre makes pretty extensive use of all the resources at its disposal, and > > having to compete with physical devices under a VM that runs as an ordinary > > user process is more than likely going to lead to resource deadlocks. > > > > I wouldn''t suggest running Lustre under VMs.Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.