<div dir="ltr">I use local nvme to drive the CI workload for the openstack community for the last year or so. It seems to work pretty well. I just created a filesystem (xfs) and mounted it to /var/lib/nova/instances<div>I moved glance to using my swift backend and it really made the download of the images much faster. </div><div><br></div><div>It depends on if the workload is going to handle HA or you are expecting to migrate machines. If the workload is ephemeral or HA can be handled in the app I think local storage is still a very viable option. </div><div><br></div><div>Simpler is better IMO</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 5, 2020 at 7:48 AM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2020-08-05 at 12:40 +0100, Sean Mooney wrote:<br>
> On Wed, 2020-08-05 at 12:19 +0100, Lee Yarwood wrote:<br>
> > On 05-08-20 05:03:29, Eric K. Miller wrote:<br>
> > > In case this is the answer, I found that in nova.conf, under the<br>
> > > [libvirt] stanza, images_type can be set to "lvm".  This looks like it<br>
> > > may do the trick - using the compute node's LVM to provision and mount a<br>
> > > logical volume, for either persistent or ephemeral storage defined in<br>
> > > the flavor.<br>
> > > <br>
> > > Can anyone validate that this is the right approach according to our<br>
> > > needs?<br>
> > <br>
> > I'm not sure if it is given your initial requirements.<br>
> > <br>
> > Do you need full host block devices to be provided to the instance?<br>
> > <br>
> > The LVM imagebackend will just provision LVs on top of the provided VG<br>
> > so there's no direct mapping to a full host block device with this<br>
> > approach.<br>
> > <br>
> > That said there's no real alternative available at the moment.<br>
> <br>
> well one alternitive to nova providing local lvm storage is to use<br>
> the cinder lvm driver but install it on all compute nodes then <br>
> use the cidner InstanceLocalityFilter to ensure the volume is alocated form the host<br>
> the vm is on.<br>
> <a href="https://docs.openstack.org/cinder/latest/configuration/block-storage/scheduler-filters.html#instancelocalityfilter" rel="noreferrer" target="_blank">https://docs.openstack.org/cinder/latest/configuration/block-storage/scheduler-filters.html#instancelocalityfilter</a><br>
> on drawback to this is that if the if the vm is moved i think you would need to also migrate the cinder volume<br>
> seperatly afterwards.<br>
by the way if you were to take this approch i think there is an nvmeof driver so you can use nvme over rdma<br>
instead of iscsi.<br>
> <br>
> > <br>
> > > Also, I have read about the LVM device filters - which is important to<br>
> > > avoid the host's LVM from seeing the guest's volumes, in case anyone<br>
> > > else finds this message.<br>
> > <br>
> >  <br>
> > Yeah that's a common pitfall when using LVM based ephemeral disks that<br>
> > contain additional LVM PVs/VGs/LVs etc. You need to ensure that the host<br>
> > is configured to not scan these LVs in order for their PVs/VGs/LVs etc<br>
> > to remain hidden from the host:<br>
> > <br>
> > <br>
> <br>
> <br>
<a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/lvm_filters" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/lvm_filters</a><br>
>  <br>
> >  <br>
> > <br>
> <br>
> <br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>~/DonnyD</div><div>C: 805 814 6800</div><div>"No mission too difficult. No sacrifice too great. Duty First"</div></div></div>