[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 17/02/16 02:06, Simon Hobson wrote:
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.

Actually, I'm pretty sure LVM simple discards the "before image" blocks that have been modified in the "after image", it doesn't actually relocate the after image blocks back to the original location. (At least, discarding a snapshot is too quick for it to be doing this, so maybe if the origin VM is written, it copies the "before image" to a new location, and then modifies the before image location with the new data).
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.
You can mount a snapshot RW, and LVM will handle keeping any writes separate from the "origin image" copy.

For example, you could:
1) Shutdown VM
2) Snapshot VM
3) Start VM
4) VM begins some data processing
5) Modify snapshot (eg, software upgrade)
6) Bootup snapshot (block networking/etc)
7) Test snapshot


Adam Goryachev Website Managers www.websitemanagers.com.au

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.