Open Stack

That is usually what we do so that boot from image also end up in something
more solid than local-storage / NFS backed stuff.

But having Ceph is a hassle, especially if I use Swift for the glance
images.

On Mon, Apr 4, 2022 at 4:45 AM Tobias Urdin <tobias.urdin at binero.com> wrote:

> Another way to make it transparent is using the RBD image backend in Nova
> and thus the instances look like they are running on local disk but is
> spawned on for
> example Ceph, however that assumes you have such a backend.
>
> In the future, which I’ve wanted for a long time, is a images backend in
> Nova that simply
> is a proxy to calling Cinder and getting a volume, that way it would be
> volumes in both cases
> but that’s a lot of work and edge cases that might need to be tuned.
>
> On 4 Apr 2022, at 00:28, Laurent Dumont <laurentfdumont at gmail.com> wrote:
>
> Bummer :(
>
> We have a couple of use cases where I would like this to be transparent
> and things to automagically-unicorn and rainbows ;)  Thanks for the insight
> Radoslaw!
>
> On Sun, Apr 3, 2022 at 8:12 AM Radosław Piliszek <
> radoslaw.piliszek at gmail.com> wrote:
>
>> On Sun, 3 Apr 2022 at 12:46, Laurent Dumont <laurentfdumont at gmail.com>
>> wrote:
>> >
>> > Got it!
>> >
>> > By quota, do you mean reserved_host_disk_mb in nova.conf? I could make
>> the /var/lib/nova/instances RO but I am not sure how that would impact
>> config drive that are created locally (since I dont have ceph)
>>
>> I meant the filesystem quota.
>> And yes, this affects config drives.
>> Unfortunately, the error message from nova might be confusing.
>>
>> > Just to be clear on the behavior, this means that boot-from-image
>> requests would fail?
>> >
>> > Looking at nova.conf, I can disable the number of local-disks
>> supported, but this doesn't act as a behavior change when the requests are
>> made.
>> >
>> > I assume, from what I now know, that there is no mechanism to
>> default/transform a request to BFV.
>> >
>> > # A negative number means unlimited. Setting max_local_block_devices
>> > # to 0 means that any request that attempts to create a local disk
>> > # will fail. This option is meant to limit the number of local discs
>> > # (so root local disc that is the result of --image being used, and
>> > # any other ephemeral and swap disks). 0 does not mean that images
>> > # will be automatically converted to volumes and boot instances from
>> > # volumes - it just means that all requests that attempt to create a
>> > # local disk will fail.
>> > #
>> > # Possible values:
>> > #
>> > # * 0: Creating a local disk is not allowed.
>> > # * Negative number: Allows unlimited number of local discs.
>> > # * Positive number: Allows only these many number of local discs.
>> > #                        (Default value is 3).
>> > #  (integer value)
>> > #max_local_block_devices = 3
>>
>> It seems this is actually the best approach (the error message now
>> makes sense). Also confirmed by the faq -
>>
>> https://opendev.org/openstack/nova/src/commit/b0851b0e9c82446aec2ea0317514766fbc53abc0/doc/source/user/block-device-mapping.rst#faqs
>>
>> -yoctozepto
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220404/8012407a/attachment-0001.htm>