[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?



billb@xxxxxxx wrote:

> That thread also suggests 
> 
> "Run a backup daemon inside the guest instead.  There are plenty of
> network backup programs around.  Choose your favorite one and install
> it in your VM."
> 
> which I think is what you're saying you're doing.

Yes. Mine are home grown scripts, but that doesn't make any difference to the 
principle.

> It'd be great if there was an approved/recommended, safe & well documented 
> way to make  point in time "snapshots" (or whatever you'd call them) of Xen 
> guests.  If it's there in the docs I didn't get to it yet.
> 
> I'm after two things.
> 
> 1st, general regular backups of production guests.
> 
> and 2nd, snapshots at various stages of guests' installs that I can store 
> away somewhere, and use to quickly spin-up a new guest in a "pre configured" 
> state.

Well there is a method - but it's not documented or (AFAIK) 
approved/recommended.
If you pause the VM, snapshot it's image AND it's disks at the same time, and 
then unpause it - you now have a snapshot at an instant in time (when you 
paused it) of the state of the guest, both it's disks, it's memory, and it's 
running processes. The downside is that the guest pauses for as long as it 
takes to copy it's state.
It is work checking if there's a facility to "snapshot" a running guest - I 
haven't looked as it's not something I'm interested in. If so then you could do 
a pause-snapshot-snapshot-unpause which would only pause the guest for 
milliseconds. I think you still need the pause-unpause otherwise there's a 
distinct lag between snapshotting the guest state and snapshotting it's disk(s).
An alternative, which I can see as an option but wouldn't know how to go about, 
would be to use co-operation from the guest to suspend writes to disk - then 
all writes will get cached, and if not cacheable then the process will block 
momentarily. So you tell the guest to suspend writes, snapshot it's disks, 
snapshot it's state, then resume writes - for most processes there will then be 
no pause at all. This only comes to mind because a raid controller in a system 
I worked on decades ago had a facility to suspend disk activity on a SCSI bus - 
and it would then either cache writes or block or read from the other disks to 
allow for (non hot-swappable) disk replacements.

As for "new installs", I did a basic install and when finished I shut it down. 
Now, when I want to spin up a new system, I can create a new volume(s), put a 
filesystem on the volume(s), copy the files over, copy a basic config file and 
adapt it, start the new guest. You could use a disk snapshot, but I prefer 
copying files as it's easier to resize a filesystem on the fly. For the base 
image I can keep the volume just big enough for the files, and when spinning up 
a new machine I can size the volume(s) to suit the expected requirements. Also, 
I keep the base image in a single volume, but when creating new guests I tend 
to split things up depending on it's function - eg most systems have /var as a 
separate volume, a mail server has /var/spool (or /var/spool/virtual) as a 
separate volume, and so on.


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


 


Rackspace

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