<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">Wow thanks for testing that.   I don't think I can preallocate on an NFS mount.  I keep getting an "Operation not supported" error.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 12:11 PM, Pádraig Brady <span dir="ltr"><<a href="mailto:P@draigbrady.com" target="_blank">P@draigbrady.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="HOEnZb"><div class="h5">On 03/04/2013 07:54 PM, Pádraig Brady wrote:<br>
> On 03/04/2013 07:19 PM, Samuel Winchenbach wrote:<br>
>> Hi All,<br>
>><br>
>> I have a cluster of three nodes set up.  Live migration is accomplished via an NFS mount over 10GigE shared by all three nodes.<br>
>><br>
>> I have noticed that when a VM is brand new I am getting close to 60MB/s disk write when using "dd if=/dev/zero of=file bs=1M count=1k conv=fdatasync". after doing this 10s of times the perfomance of the disk seems to drop  to around 4 - 12 MB/s.<br>

>><br>
>> I have also noticed that doing a live-migration causes a similar effect immediately.<br>
>><br>
>> Here is the virsh xml output of one of my VMs:  <a href="https://gist.github.com/swinchen/397fbe3bb74305064944" target="_blank">https://gist.github.com/swinchen/397fbe3bb74305064944</a><br>
>><br>
>> I have read several "tuning" guides and most of the suggestions seems to be configured already (cache='none', virtio for network, disk and memballoon).<br>
>><br>
>> Do you think qcow2 is causing my issue and if so is there a way to boot an instance and override the disk format?<br>
><br>
> qcow may possibly be the issue.<br>
><br>
> You could use raw disk images by setting the<br>
> use_cow_images=False nova config option.<br>
> The tradeoff there is slower instance start and<br>
> increased (but more guaranteed) disk usage.<br>
><br>
> Alternatively you could try to fallocate the disk<br>
> image before running the perf test like:<br>
>   # get virt_size<br>
>   qemu-img info /var/lib/nova/instances/instance-0000002f/disk<br>
>   fallocate -n -l $virt_size /var/lib/nova/instances/instance-0000002f/disk<br>
><br>
> There is also the possibility of adjusting nova<br>
> to use preallocation=metadata on the qcow images<br>
> (forfeiting CoW in the process), as discussed in "future work" at:<br>
> <a href="https://blueprints.launchpad.net/nova/+spec/preallocated-images" target="_blank">https://blueprints.launchpad.net/nova/+spec/preallocated-images</a><br>
<br>
</div></div>Just did some testing here, writing in a VM backed by a local file system, using:<br>
  dd if=/dev/zero of=file bs=1M count=1k conv=notrunc,fdatasync oflag=append<br>
<br>
I didn't see a degredation after a while, but did see<br>
quite different performance depending on the formats used:<br>
<br>
disk performance outside VM = 120MB/s<br>
raw in $instance_dir/ = 105MB/s<br>
qcow copy with preallocation=metadata in $instance_dir/ = 100MB/s<br>
qcow CoW with fallocate full size in $instance_dir/ = 55MB/s<br>
  Note perf a bit more stable than without fallocate<br>
  I didn't test with full host disk where improvements would be more noticeable<br>
qcow CoW in $instance_dir/ = 52MB/s<br>
qcow CoW in $instance_dir/ backed by qcow with preallocation=metadata in base = 52MB/s<br>
<br>
thanks,<br>
Pádraig.<br>
</blockquote></div><br></div>