If you have RAID, are all the disks working properly (no failed
disks?)?  If using software raid, what does /proc/mdstat look like?
It's not rebuilding is it?  If hardware RAID, is the controller
actually decent (very few are)?

What does your memory usage look like when it works well and when it
doesn't (how much is available to buffers)?

Is slocate running?  Is something else running doing a lot of io?
(use something like "iostat 5" and, ignoring the first line, compare
what it looks like before you start dump and the dump runs well vs.
when it won't)

On Sun, Jul 8, 2012 at 2:22 AM, Todd And Margo Chester
<[log in to unmask]> wrote:
> On 07/07/2012 02:03 PM, Nico Kadel-Garcia wrote:
>>
>> On Sat, Jul 7, 2012 at 4:38 PM, Todd And Margo Chester
>> <[log in to unmask]> wrote:
>>>
>>> On 07/07/2012 07:25 AM, Nico Kadel-Garcia wrote:
>>>>
>>>>
>>>> On Sat, Jul 7, 2012 at 6:16 AM, David Sommerseth <[log in to unmask]>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 07/06/2012 02:23 AM, Nico Kadel-Garcia wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>    By the way, if you skip using AHCI and just program the bios
>>>>>>>>    for IDE, you don't even have to use an f6 disk to install XP.
>>>>>>>>    No sign of drivers doing XP in yet.  Although the day will come.
>>>>>>>>
>>>>>>>>    Great letter.  Thank you!
>>>>>>
>>>>>>
>>>>>>
>>>>>> You didn't notice any performance issues with virtualized IDE versus
>>>>>> SCSI?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> IDE and SCSI emulation is not going to impress you on performance.
>>>>> Using
>>>>> virtio for disk access may improve the performance, and the Windows
>>>>> drivers
>>>>> should be available here:
>>>>
>>>>
>>>>
>>>> David, I belive that Todd is using "dump" to back up the
>>>> virtualization server, not the virtualization guests. The "dump"
>>>> comman dwould be completely useless for a Windows partition, whether
>>>> FAT32 or NTFS.
>>>>
>>>>> <http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers>
>>>>
>>>>
>>>>
>>>> Now, if you have to back up virtualized Windows *guest* hosts, that's
>>>> a whole other set of adventures.
>>>>
>>>
>>> I am backing up the following:
>>>
>>>
>>> $ df
>>> Filesystem           1K-blocks      Used Available Use% Mounted on
>>> /dev/mapper/luks-xx  946513204 286868552 611564524  32% /
>>>
>>> KVM, VM's are all just files on this partition.
>>
>>
>> Oh, you're backing up the *virtual images*. No wonder you're having
>> adventures, anything that writes to the disks from the active guest is
>> wending its way from the guest, through *its* file systems and
>> caching, through the *KVM server's* hosts filesystems and caching, all
>> the way to disk.
>
>
> I am going to have to work on my technical writing.  Apparently,
> I did not make it clear that I have my VM's off when I do my backups.
> It is when XP's VM has previously run that I have a problem.
>
> And, KVM is now off the hook, because, I am doing a backup and I
> have not fired off a single VM this boot cycle, and ...
>
>   DUMP: Volume 1 started with block 1 at: Sat Jul  7 22:59:37 2012
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: 1.19% done at 11362 kB/s, finished in 6:56
>   DUMP: 2.62% done at 12559 kB/s, finished in 6:11
>   DUMP: 4.05% done at 12953 kB/s, finished in 5:54
>
> It is doing its five times slower thing.  I wonder if there is something
> coincidentally I do that is causing the slowdown that
> I typically do it when I am running XP, maybe like listen to
> music while I work, or something else.
>
> I am going to have to pay close attention to what I have run
> on the Linux side when I have XP up.
>
> The game is a foot!
>
> -T