All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Haomai Wang <haomaiwang@gmail.com>, ceph-devel@vger.kernel.org
Subject: Re: [RBD][OpenStack]The way to solve problem when boot VM and root disk size is specified
Date: Tue, 12 Nov 2013 18:58:16 -0800	[thread overview]
Message-ID: <5282EAC8.90902@inktank.com> (raw)
In-Reply-To: <E7DD39A7-418B-4C08-98A2-8CB27AD18711@gmail.com>

On 11/11/2013 11:10 PM, Haomai Wang wrote:
> Hi all,
>
> Now OpenStack Nova master branch still exists a bug when you boot a VM which root disk size is specified. The storage backend of Nova also is rbd. For example, you boot a VM and specify 10G as root disk size. But the image is only 1G. Then VM will be spawned and the root disk size will expands to 10G. The filesystem still is 1G.
>
> Now I have a way to solve it. When we boot a VM and resize root disk size, we use "fuse-rbd" command to resize filesystem.
>
> fuse-rbd -p pool -c /etc/ceph/ceph.conf /tmp-ceph-rbd
> cd /tmp-ceph-rbd
> resize2fs volume-xxxxxxxxxxx
>
> It seemed to work but I want to know whether exists problems when many volumes in a pool. I'm not sure that too many volumes cause performance problem.

fuse-rbd has a 128 image limit at the moment. It's more of a prototype
than something I'd recommend relying on.

Interacting with an untrusted filesystem on a compute host is also a
bit worrying from a security perspective. If you really need to resize
the fs and can't use cloud-init, using libguestfs would be best. This
isolates the operations into a vm, so the host kernel isn't interacting
with untrusted filesystems.

Josh

  reply	other threads:[~2013-11-13  2:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  7:10 [RBD][OpenStack]The way to solve problem when boot VM and root disk size is specified Haomai Wang
2013-11-13  2:58 ` Josh Durgin [this message]
2013-11-13 13:14   ` Haomai Wang
2013-11-13 14:10     ` Haomai Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5282EAC8.90902@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=haomaiwang@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.