I mean to have 50 * 100GB qemu images as disks for the same VM and each virtual disk to be a PV for the VG of that big VM.<div id="yMail_cursorElementTracker_1611807743008"><br></div><div id="yMail_cursorElementTracker_1611807743243">Best Regards,</div><div id="yMail_cursorElementTracker_1611807755266">Strahil Nikolov<br><br><div id="ymail_android_signature"><a id="ymail_android_signature_link" href="https://go.onelink.me/107872968?pid=InProduct&amp;c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&amp;af_wl=ym&amp;af_sub1=Internal&amp;af_sub2=Global_YGrowth&amp;af_sub3=EmailSignature">Sent from Yahoo Mail on Android</a></div> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Wed, Jan 27, 2021 at 16:28, Erik Jacobson</div><div>&lt;erik.jacobson@hpe.com&gt; wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> &gt; &gt; Shortly after the sharded volume is made, there are some fuse mount<br clear="none">&gt; &gt; messages. I'm not 100% sure if this was just before or during the<br clear="none">&gt; &gt; big qemu-img command to make the 5T image<br clear="none">&gt; &gt; (qemu-img create -f raw -o preallocation=falloc<br clear="none">&gt; &gt; /adminvm/images/adminvm.img 5T)<br clear="none">&gt; Any reason to have a single disk with this size ?<br clear="none"><br clear="none">&gt; Usually in any<br clear="none">&gt; virtualization I have used , it is always recommended to keep it lower.<br clear="none">&gt; Have you thought about multiple disks with smaller size ?<br clear="none"><br clear="none">Yes, because the actual virtual machine is an admin node/head node cluster<br clear="none">manager for a supercomputer that hosts big OS images and drives<br clear="none">multi-thousand-node-clusters (boot, monitoring, image creation,<br clear="none">distribution, sometimes NFS roots, etc) . So this VM is a biggie.<br clear="none"><br clear="none">We could make multiple smaller images but it would be very painful since<br clear="none">it differs from the normal non-VM setup.<br clear="none"><br clear="none">So unlike many solutions where you have lots of small VMs with their<br clear="none">images small images, this solution is one giant VM with one giant image.<br clear="none">We're essentially using gluster in this use case (as opposed to others I<br clear="none">have posted about in the past) for head node failover (combined with<br clear="none">pacemaker).<div class="yqt8471964298" id="yqtfd87849"><br clear="none"><br clear="none">&gt; Also worth<br clear="none">&gt; noting is that RHII is supported only when the shard size is&nbsp; 512MB, so<br clear="none">&gt; it's worth trying bigger shard size .</div><br clear="none"><br clear="none">I have put larger shard size and newer gluster version on the list to<br clear="none">try. Thank you! Hoping to get it failing again to try these things!<div class="yqt8471964298" id="yqtfd09560"><br clear="none"></div> </div> </blockquote></div>