[fedora-virt] virt-install disk size problems

[James Harrison]

Hello Richard,

I tried  two things with sparse=true:
cache=None and my VM wouldnt
cache=writeback and my VM builds OK.

When I use cache=None I get the problem that I described in my 1st posting, that there is a problem mounting: /.

Is this normal?

Regards,

James

On Monday, 31 March 2014, 11:00, Richard W.M. Jones <rjones at redhat.com> wrote:
 
On Mon, Mar 31, 2014 at 09:59:22AM +0100, James Harrison wrote:
[...]

I wasn't aware that cache=none was necessary for live migration.  It
seems really broken that this is necessary, see Stefan's explanation
here:

https://groups.google.com/forum/#!topic/synnefo-devel/9MU5ujOcOt4

> Also Caching=None is set because there is a disk cache on the disk.

The qemu cache mode isn't really relevant to this.  But I guess if
your disk has a huge cache (let's say it's a SAN LUN or a very
expensive RAID controller) then enabling the host cache
(ie. cache=writeback) might be overkill.

> Would double caching would slow down I/O?

Not in my testing.  cache=writeback is a little faster.

There are some caveats:

- cache=writeback is only safe if your guest sends write barriers,
   ie.  recent Linux and recent Windows guests are OK, Linux and
   Windows prior to ~2008/2009 are NOT safe.

- Our performance team reckon that cache=none is better than
   cache=writeback, but their test configuration fully provisions host
   memory with guests.  You only benefit if your host actually has
   some free memory to give to the cache ...

- It may make migration impossible.

- Libguestfs is not representative of what real guests do.


Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/virt/attachments/20140331/89176c62/attachment.html>