Re: [Xen-users] Re: Snapshotting LVM backed guests from dom0

[chris <tknchris@xxxxxxxxx>]

Thanks everyone for the tips i will try experimenting with these over
this weekend and let you know how much it helps if any.

- chris

On Fri, Apr 23, 2010 at 3:37 PM, Nick Couchman <Nick.Couchman@xxxxxxxxx> wrote:
>> On Sat, Apr 17, 2010 at 2:53 PM, chris <tknchris@xxxxxxxxx> wrote:
>>> Just looking for some feedback from other people who do this. I know
>>> its not a good "backup" method but "crash consistent" images have been
>>> very useful for me in disaster situations just to get OS running
>>> quickly then restore data from a data backup. My typical setup is to
>>> put the LV in snapshot mode while guest is running then dd the data to
>>> a backup file which is on a NFS mount point. The thing that seems to
>>> be happening is that the VM's performance gets pretty poor during the
>>> time the copy is happening. My guesses at why this was happening were:
>>>
>>> 1.   dom0 having equal weight to the other 4 guests on the box and
>>> somehow hogging cpu time
>>> 2.   lack of QoS on the IO side / dom0 hogging IO
>>> 3.   process priorities in dom0
>>> 4.   NFS overhead
>>>
>>> For each of these items I tried to adjust things to see if it improved.
>>>
>>> 1.   Tried increasing dom0 weight to 4x the other VM's.
>
> Probably not going to help - if you increase the weight, you'll choke out 
> your other domUs, if you decrease the weight, the domUs also may be affected 
> because network and disk I/O end up going through dom0 in the end, anyway.
>
>>> 2.   Saw pasi mentioning dm-ioband a few times and think this might
>>> address IO scheduling but haven't tried it yet.
>>> 3.   Tried nice-ing the dd to lowest priority and qemu-dm to highest
>
> I would expect this to help, some, but may not be the only thing.  Also, 
> remember that network and disk I/O are still done through drivers on dom0, 
> which means pushing qemu-dm to the highest really won't buy you anything.  I 
> would expect re-niceing dd to help some, though.
>
>>> 4.   Changing destination to a local
>
> This indicates that the bottleneck is local and not the network.  The next 
> step would be to grab some Linux performance monitoring and debugging tools 
> and figure out where your bottleneck is.   So, things like top, xentop, 
> iostat, vmstat, and sar may be useful in determining what component is 
> hitting its performance limit and needs to be tweaked or worked around.
>
> -Nick
>
>
>
>
> --------
> This e-mail may contain confidential and privileged material for the sole use 
> of the intended recipient.  If this email is not intended for you, or you are 
> not responsible for the delivery of this message to the intended recipient, 
> please note that this message may contain SEAKR Engineering (SEAKR) 
> Privileged/Proprietary Information.  In such a case, you are strictly 
> prohibited from downloading, photocopying, distributing or otherwise using 
> this message, its contents or attachments in any way.  If you have received 
> this message in error, please notify us immediately by replying to this 
> e-mail and delete the message from your mailbox.  Information contained in 
> this message that does not relate to the business of SEAKR is neither 
> endorsed by nor attributable to SEAKR.
>

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users