Hi, If a VM is using a file backed disk through the means of a loop-back device, is there a risk that the image file may not be consistent given that dom0 which does the loop-back mount of the file may be caching certain portions of that file? For example, if on dom0 I have a disk.img and I configure my domU to use that file as it''s virtual disk through a loop back device driver, while domU is running or even paused, it''s virtual disk may not be completely synced with the actual image file backing that disk, right? Does the use of the blktap driver eliminate this problem? My overall goal is to be able to take periodic, incremental snapshots of the VM''s disks. I thought about using LVM2''s snapshotting functionality as well as ZFS. Any recommendations as to the best way to take incremental snapshots of a file backed virtual disk? Thanks, Mike _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, Jan 27, 2011 at 5:00 PM, Mike Sun <msun@gatech.edu> wrote:> Does the use of the blktap > driver eliminate this problem?no, since it''s not a virtualization isse: the guest''s OS might have a lot of uncommitted data, no setup of Xen can divine what should be on disk before the guest chooses to flush it. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I''m not worried about uncommitted data from the guest OS... I''m capturing all of the domU memory state as well, so I guess I should be more clear that I''m not looking for truly "consistent" disk image... I just want to make sure that the virtual disk state is always synced to the actual backing file. On Thu, Jan 27, 2011 at 5:23 PM, Javier Guerra Giraldez <javier@guerrag.com> wrote:> On Thu, Jan 27, 2011 at 5:00 PM, Mike Sun <msun@gatech.edu> wrote: >> Does the use of the blktap >> driver eliminate this problem? > > no, since it''s not a virtualization isse: the guest''s OS might have a > lot of uncommitted data, no setup of Xen can divine what should be on > disk before the guest chooses to flush it. > > -- > Javier >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Jan 28, 2011 at 5:00 AM, Mike Sun <msun@gatech.edu> wrote:> Hi, > > If a VM is using a file backed disk through the means of a loop-back > device, is there a risk that the image file may not be consistent > given that dom0 which does the loop-back mount of the file may be > caching certain portions of that file?There are problems with loopback driver, but I don''t think it''s one of them.> For example, if on dom0 I have > a disk.img and I configure my domU to use that file as it''s virtual > disk through a loop back device driver, while domU is running or even > paused, it''s virtual disk may not be completely synced with the actual > image file backing that disk, right? Does the use of the blktap > driver eliminate this problem?See "Advantages" on http://wiki.xensource.com/xenwiki/blktap -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Il 27/01/2011 23:00, Mike Sun ha scritto:> Hi,[cut]> My overall goal is to be able to take periodic, incremental snapshots > of the VM''s disks. I thought about using LVM2''s snapshotting > functionality as well as ZFS. Any recommendations as to the best way > to take incremental snapshots of a file backed virtual disk?suse sles 11 sp1 can snapshot a vm (disk+status+mem) if you use qcow2 disk format. Christian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mike Sun wrote:>I''m not worried about uncommitted data from the guest OS... I''m >capturing all of the domU memory state as well, so I guess I should be >more clear that I''m not looking for truly "consistent" disk image... I >just want to make sure that the virtual disk state is always synced to >the actual backing file.As long as you pause the guest and snapshot BOTH it''s disk and machine state at the same instant (relative to guest operations) then between them you will have a consistent backup. BUT the ONLY way to use that backup is to restore both the disk image AND machine state and unpause the guest from that state. Any attempt to read the filesystem directly will result in reading dirty data which would be analogous to having pulled the power plug on the guest at the instant the snapshot was taken. Any uncommitted writes in the guest will be captured by the guest machine state, any uncommitted write in the host OS will be read as they would for any other write - as in a read of the file will use any dirty data waiting in the write cash rather than reading what is now invalid data from disk. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 01/28/11 09:36, Simon Hobson wrote:> Mike Sun wrote: >> I''m not worried about uncommitted data from the guest OS... I''m >> capturing all of the domU memory state as well, so I guess I should be >> more clear that I''m not looking for truly "consistent" disk image... I >> just want to make sure that the virtual disk state is always synced to >> the actual backing file. > > As long as you pause the guest and snapshot BOTH it''s disk and machine > state at the same instant (relative to guest operations) then between > them you will have a consistent backup. BUT the ONLY way to use that > backup is to restore both the disk image AND machine state and unpause > the guest from that state. Any attempt to read the filesystem directly > will result in reading dirty data which would be analogous to having > pulled the power plug on the guest at the instant the snapshot was taken. > > Any uncommitted writes in the guest will be captured by the guest > machine state, any uncommitted write in the host OS will be read as > they would for any other write - as in a read of the file will use any > dirty data waiting in the write cash rather than reading what is now > invalid data from disk. >isn''t pausing and saving the machine state actually the same as saving the machine (xm save)? B. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> isn''t pausing and saving the machine state actually the same as saving > the machine (xm save)?Yup it is, but xm save doesn''t snapshot the disk. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users