Gluster users - Jan 2021 - qemu raw image file - qemu and grub2 can't find boot content from VM

> > Shortly after the sharded volume is made, there are some fuse mount
> > messages. I'm not 100% sure if this was just before or during the
> > big qemu-img command to make the 5T image
> > (qemu-img create -f raw -o preallocation=falloc
> > /adminvm/images/adminvm.img 5T)
> Any reason to have a single disk with this size ?
> Usually in any
> virtualization I have used , it is always recommended to keep it lower.
> Have you thought about multiple disks with smaller size ?
Yes, because the actual virtual machine is an admin node/head node cluster
manager for a supercomputer that hosts big OS images and drives
multi-thousand-node-clusters (boot, monitoring, image creation,
distribution, sometimes NFS roots, etc) . So this VM is a biggie.

We could make multiple smaller images but it would be very painful since
it differs from the normal non-VM setup.

So unlike many solutions where you have lots of small VMs with their
images small images, this solution is one giant VM with one giant image.
We're essentially using gluster in this use case (as opposed to others I
have posted about in the past) for head node failover (combined with
pacemaker).
> Also worth
> noting is that RHII is supported only when the shard size is  512MB, so
> it's worth trying bigger shard size .
I have put larger shard size and newer gluster version on the list to
try. Thank you! Hoping to get it failing again to try these things!

I think the following messages are not harmful;

[2021-01-26 19:28:40.652898] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/48bb5288-e27e-46c9-9f7c-944a804df361.1: dentry not found in
48bb5288-e27e-46c9-9f7c-944a804df361
[2021-01-26 19:28:40.652975] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/931508ed-9368-4982-a53e-7187a9f0c1f9.3: dentry not found in
931508ed-9368-4982-a53e-7187a9f0c1f9
[2021-01-26 19:28:40.653047] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/e808ecab-2e70-4ef3-954e-ce1b78ed8b52.4: dentry not found in
e808ecab-2e70-4ef3-954e-ce1b78ed8b52
[2021-01-26 19:28:40.653102] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/2c62c383-d869-4655-9c03-f08a86a874ba.6: dentry not found in
2c62c383-d869-4655-9c03-f08a86a874ba
[2021-01-26 19:28:40.653169] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/556ffbc9-bcbe-445a-93f5-13784c5a6df1.2: dentry not found in
556ffbc9-bcbe-445a-93f5-13784c5a6df1
[2021-01-26 19:28:40.653218] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/5d414e7c-335d-40da-bb96-6c427181338b.5: dentry not found in
5d414e7c-335d-40da-bb96-6c427181338b
[2021-01-26 19:28:40.653314] W [MSGID: 101159]
[inode.c:1212:__inode_unlink] 0-inode: be318638-e8a0-4c6d-977d-7a937a
a84806/43364dc9-2d8e-4fca-89d2-e11dee6fcfd4.8: dentry not found in
43364dc9-2d8e-4fca-89d2-e11dee6fcfd4

Also, I would like to point that I have VMs with large disks 1TB and 2TB,
and have no issues. definitely would upgrade Gluster version like let's say
at least 7.9.
Amar also asked a question regarding enabling Sharding in the volume after
creating the VMs disks, which would certainly mess up the volume if that
what happened.

On Wed, Jan 27, 2021 at 5:28 PM Erik Jacobson <erik.jacobson at hpe.com>
wrote:
> > > Shortly after the sharded volume is made, there are some fuse
mount
> > > messages. I'm not 100% sure if this was just before or during
the
> > > big qemu-img command to make the 5T image
> > > (qemu-img create -f raw -o preallocation=falloc
> > > /adminvm/images/adminvm.img 5T)
> > Any reason to have a single disk with this size ?
>
> > Usually in any
> > virtualization I have used , it is always recommended to keep it
lower.
> > Have you thought about multiple disks with smaller size ?
>
> Yes, because the actual virtual machine is an admin node/head node cluster
> manager for a supercomputer that hosts big OS images and drives
> multi-thousand-node-clusters (boot, monitoring, image creation,
> distribution, sometimes NFS roots, etc) . So this VM is a biggie.
>
> We could make multiple smaller images but it would be very painful since
> it differs from the normal non-VM setup.
>
> So unlike many solutions where you have lots of small VMs with their
> images small images, this solution is one giant VM with one giant image.
> We're essentially using gluster in this use case (as opposed to others
I
> have posted about in the past) for head node failover (combined with
> pacemaker).
>
> > Also worth
> > noting is that RHII is supported only when the shard size is  512MB,
so
> > it's worth trying bigger shard size .
>
> I have put larger shard size and newer gluster version on the list to
> try. Thank you! Hoping to get it failing again to try these things!
>

-- 
Respectfully
Mahdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20210127/490a79c4/attachment.html>

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.
Best Regards,Strahil Nikolov

Sent from Yahoo Mail on Android 
 
  On Wed, Jan 27, 2021 at 16:28, Erik Jacobson<erik.jacobson at hpe.com>
wrote:   > > Shortly after the sharded volume is made, there are some fuse
mount
> > messages. I'm not 100% sure if this was just before or during the
> > big qemu-img command to make the 5T image
> > (qemu-img create -f raw -o preallocation=falloc
> > /adminvm/images/adminvm.img 5T)
> Any reason to have a single disk with this size ?
> Usually in any
> virtualization I have used , it is always recommended to keep it lower.
> Have you thought about multiple disks with smaller size ?
Yes, because the actual virtual machine is an admin node/head node cluster
manager for a supercomputer that hosts big OS images and drives
multi-thousand-node-clusters (boot, monitoring, image creation,
distribution, sometimes NFS roots, etc) . So this VM is a biggie.

We could make multiple smaller images but it would be very painful since
it differs from the normal non-VM setup.

So unlike many solutions where you have lots of small VMs with their
images small images, this solution is one giant VM with one giant image.
We're essentially using gluster in this use case (as opposed to others I
have posted about in the past) for head node failover (combined with
pacemaker).
> Also worth
> noting is that RHII is supported only when the shard size is? 512MB, so
> it's worth trying bigger shard size .
I have put larger shard size and newer gluster version on the list to
try. Thank you! Hoping to get it failing again to try these things!
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20210128/42c83da5/attachment.html>