Re: [Xen-users] How to list the drives a DomU is using, and their types -- with or without a parition -- from the Dom0?

[Simon Hobson <linux@xxxxxxxxxxxxxxxx>]

billb@xxxxxxx wrote:

> I'd thought that Xen 'figured out' what kind of disk structure it's mounting.

The "disk structure" as far as Xen is concerned is ... a "disk". Just a 
collection of blocks.

> I thought that snaps had to remain 'in' the VG, and they can get kind of 
> large.

A snapshot is simply a virtual image of the volume at a point in time. In terms 
of what you see when you look into it, it is exactly the same size as the 
volume - though the underlying representation of it will grow over time 
(starting from near enough zero space). So if you wanted to backup that 
snapshot, you'd treat it like a disk and image it - what you do with the image 
is then up to you.
When you are done, remember to delete the snapshot or it will slow performance* 
and eat disk space*.

A couple of caveats though.
If you snapshot the volume, what you see is the same as if you unceremoniously 
yanked the power cord on a physical machine - anything still held in the 
guest's dirty cache will not be there. You can minimise this by triggering the 
guest to sync it's cache, and of course using a journaled filesystem - but you 
cannot completely eliminate it.

The way some virtualisation & backup systems handle this is (to simplify "a 
bit") to make the combination of hypervisor, guest OS, and backup system 
intimately aware of each other so that the backup system can copy what the 
guest has, not what it has already written to disk.

Personally, I work the other way - I do backups from within the guest using 
rsync to maintain a clone of the filesystem as seen by the guest on one central 
device. From there I generate multiple generations with file de-dupe etc as a 
separate off-line task. One area where if you ask 10 people you'll get 11 
opinions :-)

* It's worth considering the way snapshots work.
AIUI in LVM, when you make a snapshot, what is on-disk is kept as the "before 
image". Any writes then go into a separate "after image" area which starts at 
zero and grows. Anything accessing the snapshot gets the before image data, 
anything accessing the live volume gets the data from the after image if there 
is a corresponding block, or the before image data if it's not been altered. 
Over time the after-image data set grows - and performance will be affected as 
the data gets fragmented.
When you destroy the snapshot, any data in the after image is then copied into 
the main volume and after that the after image is deleted.

I would not have thought that you could safely mount a snapshot. If you try 
mounting it read-only then you have a dirty filesystem. If you mount it 
read-write then fsck will try and fix it, which then means you have two 
different systems trying to write to a volume. I don't know if LVM will handle 
this and prevent the host access from corrupting the guests filesystem.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users