My first thought was to do a singled fixed disk and never resize that disk at all. If you need space, you have to use a volume service. <div><br></div><div>Ultimately, I don't think this the right approach either, but it solves the initial use case of needing more storage space. </div>
<div><br></div><div><br><br><div class="gmail_quote">On Fri, Sep 2, 2011 at 11:34 AM, Chris Behrens <span dir="ltr"><<a href="mailto:chris.behrens@rackspace.com">chris.behrens@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Sep 2, 2011, at 8:07 AM, Paul Voccio wrote:<br>
<br>
> On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen <<a href="mailto:soren@linux2go.dk">soren@linux2go.dk</a>> wrote:<br>
</div>> [...]<br>
<div class="im">> The potential for filesystem bugs that could bring the host down gives<br>
> me the heebie jeebies. I really, really don't want to mount people's<br>
> filesystems.<br>
><br>
><br>
> Can you explain a bit more here? I would like to understand your concerns. I would advocate mounting in a utility VM if you mean to protect from mounting instance with malicious data. We may have to do this to expand partitions or resize down for Windows.<br>

<br>
</div>Mounting someone's filesystem should not be necessary if we have certain restrictions on the management.  I.e., we could say we will only resize the last filesystem in the partition table.  That would avoid needing to know the filesystem layout in the image (looking at /etc/fstab or updating it).  Not sure that's a desired restriction, however.<br>

<br>
That said, we'd still need to attach the VM disk somewhere and run fs resize utils... and it might still be best to do this in a utility VM.<br>
<font color="#888888"><br>
- Chris<br>
</font><div><div></div><div class="h5"><br>
This email may include confidential information. If you received it in error, please delete it.<br>
<br>
</div></div></blockquote></div><br></div>