<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 19, 2016 at 8:47 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">One feature I think we would like to see that could benefit from LVM is some kind of multidisk support with better fault tolerance....<br>
<br>
For example:<br>
Say you have a node, and there are 20 vm's on it, and thats all the disk io it could take. But say you have spare cpu/ram capacity other then the diskio being used up. It would be nice to be able to add a second disk, and be able to launch 20 more vm's, located on the other disk.<br>
<br>
If you combined them together into one file system (linear append or raid0), you could loose all 40 vm's if something went wrong. That may be more then you want to risk. If you could keep them as separate file systems or logical volumes (maybe with contigous lv's?) Each vm could only top out a spindle, but it would be much more fault tolerant to failures on the machine. I can see some cases where that tradeoff between individual vm performance and number of vm's affected by a device failure can lean in that direction.<br>
<br>
Thoughts?</blockquote><div><br></div>This is simple enough for a compute host. However, the real problem is in the scheduler. The scheduler needs to be aware that there are multiple distinct resource pools on the host. For e.g., if your 2 pools have 20G of disk each, that doesn't mean you can spin up an instance with 30G. This is the same problem the VMware driver has, and to the best of my knowledge there's still no solution to that.<div class="gmail_extra"><br></div><div> Matt</div></div>
</div></div>