6,534
edits
Changes
m
where /ploop.image is full path to new image file and 1g is block-device size
equal to 1GB. These commands succeed only if the file /ploop.image didn't
exist at the time of running "ploop init".
== Load modules ==
It's not always required to load both pfmt_ploop1 (support of ploop1 format) and
pfmt_raw (support of raw format). If we're going to use ploop1 image file,
loading pfmt_raw can be omitted. If we're going to use raw image file and have no
plans to snapshot it, pfmt_ploop1 can be omitted.
== Create device It's not always required to load both <code>pfmt_ploop1</code> (support of ploop1 format) and<code>pfmt_raw</code> (support of raw format). If we're going to use ploop1 image file ==,loading <code>pfmt_raw</code> can be omitted. If we're going to use raw image file and have noplans to snapshot it, <code>pfmt_ploop1</code> can be omitted.
# mknod /dev/ploop0 b 182 0== Initialize image file ==
This example above uses 0 as minor number. In practice, it can be any multiple
of 16 in 0..1048575 range: 0, 16, 32, 48, etc.
Other minors (not multiple In-kernel ploop operates on image files of 16) are reserved for partitions. E.g"<code>raw</code>" or "<code>ploop1</code>" format. if primarypartition number 1 is An image file should be created on /dev/ploop0, /dev/ploop0p1 will have minorand initialized (entirely in user-space)equal before asking in-kernel ploop to 1start using it.
== Bind To just create and initialize a ploop to image file ==with a GPT partition table and an ext4 filesystem inside:
Assuming that steps 2 # ploop init -s 1g -4 were done, the following commands are used to "mount"t ext4 /ploop device over .image file.
For ploop1 format:where <code>/ploop.image</code> is full path to new image file and 1g is block-device sizeequal to 1GB. This command succeed only if the file <code>/ploop.image</code> didn'texist at the time of running "<code>ploop init</code>".
# ploop mount -f ploop1 -d /dev/ploop0 /ploop.image== Mount ==
For raw format:Assuming that previous steps were done, the following command is used to "mount"ploop device over image file.
fixed some typos
This document explains how to use user-space <code>ploop </code> utility for typical
use-cases.
{{Warning|The commands below are low-level stuff. It's better to use vzctl which has all the features in place.}}
== Getting help ==
All user-space ploop management operations are available via "<code>ploop</code>"
utility. Run it w/o args to get help:
# ploop init
== Initialize image file Load modules == In-kernel ploop operates on image files of "raw" or "ploop1" format.An image file should be created and initialized (entirely in user-space)before asking in-kernel ploop to start using it. To create and initialize image file of "ploop1" format: # ploop init -s 1g -f ploop1 /ploop.image the same for "raw" format: # ploop init -s 1g -f raw /ploop.image
Further ploop commands assume that all necessary modules are loaded:
# modprobe pio_direct
# ploop mount -f raw -d /dev/ploop0 /ploop.image
Since this point, <code>/dev/ploop0 ploopXXXX</code> is operable. One can read/write any data from/toit (e.g. with "dd"), manipulate partition table on it (with "fdisk"<code>parted</code>, since ploop uses GUID Partition Table, or GPT), formatit with <code>mkfs.ext4 </code> and mount it on some mount-point. In the other words, sincenow <code>/dev/ploop0 </code> can be used as any other ordinary block device.
== Snapshot ==
Let <code>/dev/ploop0 </code> be a ploop device running over <code>/ploop.image </code> (i.e. step 4 5 wasdone) and <code>/ploop-delta.image </code> - some full path to non-existent file. Then the
command:
will create empty "ploop1" image file and register it in kernel ploop
forming "snapshotted" configuration <code>top_delta--→ base_delta</code>base_delta where <code>base_delta</code>is <code>/ploop.image </code> and <code>top_delta </code> is <code>/ploop-delta.image</code>.
Since now, all i/o targeted at <code>/dev/ploop0 </code> will change only <code>top_delta</code>.
Actually, while performing snapshot operation in kernel, ploop re-open
<code>base_delta "</code> read-only". So, when "<code>ploop snapshot</code>" is completed, it's quite safe,for example, to backup <code>base_delta</code>.
It's allowable to snapshot snapshotted configuration. Following example above,
# ploop snapshot -d /dev/ploop0 /ploop-delta1.image
will form <code>top_delta-->→ delta--→ base_delta</code>base_delta configuration where:
top_delta := /ploop-delta1.image
All deltas in snapshotted configuration are enumerated in kernel ploop in
the natural order starting from 0 for <code>base_delta</code>:
base_delta' number is 0
=== Offline merge ===
ploop has no heruistic heuristic about determining raw/ploop1 format of image file. So,
in case of offline merge, user should specify the format of base_delta
explicitly. If it's ploop1, merge command looks like:
# ploop merge /ploop-d2.image /ploop-d1.image /ploop-d.image /ploop.image
This will merge /ploop-d2.image, /ploop-d1.image and /ploop-d.image into
/ploop.image.
When merge completed, source deltas can be deleted because all data that
was present in them has been copied to destination delta.
For raw format, "-f raw" should be added as option. E.g.:
In this case "ploop copy" on node02 will write data to standard output
in some special binary format and "ploop copy" on node01 will read data
from stndard standard input, parse that special format and store data in
/home/ploop1.image ("-s" stands for "source", "-d" stands for "destination").
This should work if standard output of node02 and standard input of node01
== Grow ploop device ==
"ploop grow" command is to extend image file as neccessary necessary (offline or online)and propogate propagate new block-device size to linux kernel (in online case).
=== Offline grow ===
=== Online grow ===
Assuming that /dev/ploop0 is runnung running ploop device, the command:
# ploop grow -s 32g -d /dev/ploop0
will re-arrange underlying image file, update internal kernel ploop structures
and propogate propagate changes to linux kernel making ploop device 32GB size long.
If user had ext4 formatted and mounted on /dev/ploop0, ext4 fs can be extended
someone mounted ext4 on ploop device w/o balloon_ino option, then created
empty balloon file there, found out its inode number and saved it for the
future use).
Currently, only online ballooning is supported. The following command performs
mounted to.
If balloon file was empty, the command above simply iflates inflates it to become
1GB size. If it was non-empty but smaller than 1GB, that command extends it
to given size (1GB). If it was non-empty but larger that 1GB, that
# ploop balloon status -d /dev/ploop0 -m /mnt_ploop
will report current in-kernel status of maintainance maintenance like "merge in progress",
"grow in progress", "ballooning started", etc. This is useful because on the
one hand balloon operation can't be performed while merge or grow is in
# ploop balloon clear -d /dev/ploop0 -m /mnt_ploop
will flush stale in-kernel "BALLOON" state of maintainancemaintenance. This is useful if
previous "ploop balloon" died early leaving in-kernel ploop locked.
user monitors exit status of ploop commands he/she runs in some way. If
user issued "ploop balloon change" and it was killed in the middle, the user
knows that it didn't complete with zero exit status. Then user shoud should inquirecurrent maintainance maintenance state with "ploop balloon status" command, and, if it
reported "FBLOAD" or "RELOC", the user should use "ploop balloon complete"
before proceeding with any other maintainance maintenance operations (shanphsotsnapshot, merge,
grow, balloon).
will check whether existent balloon file was properly processed. This is useful
if previous "ploop balloon" was interrupted, but "ploop balloon status"
reports "OFF" or "BALLOON" maintainance maintenance state. In this case it's possible
that balloon file was inflated but no further processing happened.
This command does essentially the same as "ploop balloon change" but w/o
inflating balloon.
== See also ==
* [[Ploop]]
* {{Man|ploop|8}}
[[Category: Storage]]
