|
[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). You can mount a snapshot RW, and LVM will handle keeping any writes separate from the "origin image" copy.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. 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 Regards, Adam -- Adam Goryachev Website Managers www.websitemanagers.com.au _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |