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.

This is...... guaranteed to be adventure filled, as you've noticed.
Why not factor off LVM partitions for your guests? Then you can LVM
snapshot the partition with the guest diisk image, and image a
guaranteed static object instead of a file that's being writte and
asynchronously being written to disk, then relying on what's on disk
to be in any way usable?

It ain't perfect unless you can get the guest OS stopped or suspended
with you make the image, but it's likely to be a lot cleaner and
faster than the chain of destabilizing and performance sensitive
complexities you're working your way through now.