1LVMSYSTEMID(7) LVMSYSTEMID(7)
2
6 lvmsystemid — LVM system ID
7
10 The lvm(8) system ID restricts Volume Group (VG) access to one host.
11 This is useful when a VG is placed on shared storage devices, or when
12 local devices are visible to both host and guest operating systems. In
13 cases like these, a VG can be visible to multiple hosts at once, and
14 some mechanism is needed to protect it from being used by more than one
15 host at a time.
16 A VG's system ID identifies one host as the VG owner. The host with a
18 matching system ID can use the VG and its LVs, while LVM on other hosts
19 will ignore it. This protects the VG from being accidentally used from
20 other hosts.
21 The system ID is a string that uniquely identifies a host. It can be
23 configured as a custom value, or it can be assigned automatically by
24 LVM using some unique identifier already available on the host, e.g.
25 machine-id or uname.
26 When a new VG is created, the system ID of the local host is recorded
28 in the VG metadata. The creating host then owns the new VG, and LVM on
29 other hosts will ignore it. When an existing, exported VG is imported
30 (vgimport), the system ID of the local host is saved in the VG meta‐
31 data, and the importing host owns the VG.
32 A VG without a system ID can be used by LVM on any host where the VG's
34 devices are visible. When system IDs are not used, device filters
35 should be configured on all hosts to exclude the VG's devices from all
36 but one host.
37 A foreign VG is a VG seen by a host with an unmatching system ID, i.e.
39 the system ID in the VG metadata does not match the system ID config‐
40 ured on the host. If the host has no system ID, and the VG does, the
41 VG is foreign and LVM will ignore it. If the VG has no system ID,
42 access is unrestricted, and LVM can access it from any host, whether
43 the host has a system ID or not.
44 Changes to a host's system ID and a VG's system ID can be made in lim‐
46 ited circumstances (see vgexport and vgimport). Improper changes can
47 result in a host losing access to its VG, or a VG being accidentally
48 damaged by access from an unintended host. Even limited changes to the
49 VG system ID may not be perfectly reflected across hosts. A more
50 coherent view of shared storage requires an inter-host locking system
51 to coordinate access and update caches.
52 Valid system ID characters are the same as valid VG name characters.
54 If a system ID contains invalid characters, those characters are omit‐
55 ted and remaining characters are used. If a system ID is longer than
56 the maximum name length, the characters up to the maximum length are
57 used. The maximum length of a system ID is 128 characters.
58 Print the system ID of a VG to check if it is set:
60 vgs -o systemid VG
62 Print the system ID of the local host to check if it is configured:
64 lvm systemid
66 Limitations and warnings
69 To benefit fully from system ID, all hosts should have a system ID con‐
70 figured, and all VGs should have a system ID set. Without any method
71 to restrict access, e.g. system ID or device filters, a VG that is vis‐
72 ible to multiple hosts can be accidentally damaged or destroyed.
73 · A VG without a system ID can be used without restriction from any
76 host where it is visible, even from hosts that have a system ID.
77 · Many VGs will not have a system ID set because LVM has not enabled it
80 by default, and even when enabled, many VGs were created before the
81 feature was added to LVM or enabled. A system ID can be assigned to
82 these VGs by using vgchange --systemid (see below).
83 · Two hosts should not be assigned the same system ID. Doing so
86 defeats the purpose of distinguishing different hosts with this
87 value.
88 · Orphan PVs (or unused devices) on shared storage are unprotected by
91 the system ID feature. Commands that use these PVs, such as vgcreate
92 or vgextend, are not prevented from performing conflicting operations
93 and corrupting the PVs. See the orphans section for more informa‐
94 tion.
95 · The system ID does not protect devices in a VG from programs other
98 than LVM.
99 · A host using an old LVM version (without the system ID feature) will
102 not recognize a system ID set in VGs. The old LVM can read a VG with
103 a system ID, but is prevented from writing to the VG (or its LVs).
104 The system ID feature changes the write mode of a VG, making it
105 appear read-only to previous versions of LVM.
106 This also means that if a host downgrades to the old LVM version, it
108 would lose access to any VGs it had created with a system ID. To
109 avoid this, the system ID should be removed from local VGs before
110 downgrading LVM to a version without the system ID feature.
111 Types of VG access
115 A local VG is meant to be used by a single host.
116 A shared or clustered VG is meant to be used by multiple hosts.
118 These can be further distinguished as:
120 Unrestricted: A local VG that has no system ID. This VG type is unpro‐
122 tected and accessible to any host.
123 Owned: A local VG that has a system ID set, as viewed from the host
125 with a matching system ID (the owner). This VG type is acessible to
126 the host.
127 Foreign: A local VG that has a system ID set, as viewed from any host
129 with an unmatching system ID (or no system ID). It is owned by another
130 host. This VG type is not accessible to the host.
131 Exported: A local VG that has been exported with vgexport and has no
133 system ID. This VG type can only be accessed by vgimport which will
134 change it to owned.
135 Shared: A shared or "lockd" VG has the lock_type set and has no system
137 ID. A shared VG is meant to be used on shared storage from multiple
138 hosts, and is only accessible to hosts using lvmlockd. Applicable only
139 if LVM is compiled with lvmlockd support.
140 Clustered: A clustered or "clvm" VG has the clustered flag set and has
142 no system ID. A clustered VG is meant to be used on shared storage
143 from multiple hosts, and is only accessible to hosts using clvmd.
144 Applicable only if LVM is compiled with clvm support.
145 Host system ID configuration
149 A host's own system ID can be defined in a number of ways. lvm.conf
150 global/system_id_source defines the method LVM will use to find the
151 local system ID:
152 none
155 LVM will not use a system ID. LVM is allowed to access VGs
157 without a system ID, and will create new VGs without a system
158 ID. An undefined system_id_source is equivalent to none.
159 lvm.conf
161 global {
162 system_id_source = "none"
163 }
164 machineid
167 The content of /etc/machine-id is used as the system ID if
169 available. See machine-id(5) and systemd-machine-id-setup(1) to
170 check if machine-id is available on the host.
171 lvm.conf
173 global {
174 system_id_source = "machineid"
175 }
176 uname
179 The string utsname.nodename from uname(2) is used as the system
181 ID. A uname beginning with "localhost" is ignored and equiva‐
182 lent to none.
183 lvm.conf
185 global {
186 system_id_source = "uname"
187 }
188 lvmlocal
191 The system ID is defined in lvmlocal.conf local/system_id.
193 lvm.conf
195 global {
196 system_id_source = "lvmlocal"
197 }
198 lvmlocal.conf
200 local {
201 system_id = "example_name"
202 }
203 file
206 The system ID is defined in a file specified by lvm.conf
208 global/system_id_file.
209 lvm.conf
211 global {
212 system_id_source = "file"
213 system_id_file = "/path/to/file"
214 }
215 Changing system_id_source will likely cause the system ID of the host
218 to change, which will prevent the host from using VGs that it previ‐
219 ously used (see extra_system_ids below to handle this.)
220 If a system_id_source other than none fails to produce a system ID
222 value, it is the equivalent of having none. The host will be allowed
223 to access VGs with no system ID, but will not be allowed to access VGs
224 with a system ID set.
225 Overriding system ID
229 In some cases, it may be necessary for a host to access VGs with dif‐
230 ferent system IDs, e.g. if a host's system ID changes, and it wants to
231 use VGs that it created with its old system ID. To allow a host to
232 access VGs with other system IDs, those other system IDs can be listed
233 in lvmlocal.conf local/extra_system_ids.
234 lvmlocal.conf
236 local {
237 extra_system_ids = [ "my_other_name" ]
238 }
239 A safer option may be configuring the extra values as needed on the
241 command line as:
242 --config 'local/extra_system_ids=["id"]'
243 vgcreate
247 In vgcreate, the host running the command assigns its own system ID to
248 the new VG. To override this and set another system ID:
249 vgcreate --systemid SystemID VG PVs
251 Overriding the host's system ID makes it possible for a host to create
253 a VG that it may not be able to use. Another host with a system ID
254 matching the one specified may not recognize the new VG without manu‐
255 ally rescanning devices.
256 If the --systemid argument is an empty string (""), the VG is created
258 with no system ID, making it accessible to other hosts (see warnings
259 above.)
260 report/display
264 The system ID of a VG is displayed with the "systemid" reporting
265 option.
266 Report/display commands ignore foreign VGs by default. To report for‐
268 eign VGs, the --foreign option can be used. This causes the VGs to be
269 read from disk. Because lvmetad caching is not used, this option can
270 cause poor performance.
271 vgs --foreign -o +systemid
273 When a host with no system ID sees foreign VGs, it warns about them as
275 they are skipped. The host should be assigned a system ID, after which
276 standard reporting commands will silently ignore foreign VGs.
277 vgexport/vgimport
281 vgexport clears the system ID.
282 Other hosts will continue to see a newly exported VG as foreign because
284 of local caching (when lvmetad is used). Manually updating the local
285 lvmetad cache with pvscan --cache will allow a host to recognize the
286 newly exported VG.
287 vgimport sets the VG system ID to the system ID of the host doing the
289 import. vgimport automatically scans storage for newly exported VGs.
290 After vgimport, the exporting host may continue to see the VG as
292 exported, and not owned by the new host. Manually updating the local
293 cache with pvscan --cache will allow a host to recognize the newly
294 imported VG as foreign.
295 vgchange
299 A host can change the system ID of its own VGs, but the command
300 requires confirmation because the host may lose access to the VG being
301 changed:
302 vgchange --systemid SystemID VG
304 The system ID can be removed from a VG by specifying an empty string
306 ("") as the new system ID. This makes the VG accessible to other hosts
307 (see warnings above.)
308 A host cannot directly change the system ID of a foreign VG.
310 To move a VG from one host to another, vgexport and vgimport should be
312 used.
313 To forcibly gain ownership of a foreign VG, a host can temporarily add
315 the foreign system ID to its extra_system_ids list, and change the sys‐
316 tem ID of the foreign VG to its own. See Overriding system ID above.
317 shared VGs
321 A shared VG has no system ID set, allowing multiple hosts to use it via
322 lvmlockd. Changing a VG to shared will clear the existing system ID.
323 Applicable only if LVM is compiled with lvmlockd support.
324 clustered VGs
328 A clustered/clvm VG has no system ID set, allowing multiple hosts to
329 use it via clvmd. Changing a VG to clustered will clear the existing
330 system ID. Changing a VG to not clustered will set the system ID to
331 the host running the vgchange command.
332 creation_host
336 In vgcreate, the VG metadata field creation_host is set by default to
337 the host's uname. The creation_host cannot be changed, and is not used
338 to control access. When system_id_source is "uname", the system_id and
339 creation_host fields will be the same.
340 orphans
343 Orphan PVs are unused devices; they are not currently used in any VG.
344 Because of this, they are not protected by a system ID, and any host
345 can use them. Coordination of changes to orphan PVs is beyond the
346 scope of system ID. The same is true of any block device that is not a
347 PV.
348 The effects of this are especially evident when LVM uses lvmetad
350 caching. For example, if multiple hosts see an orphan PV, and one host
351 creates a VG using the orphan, the other hosts will continue to report
352 the PV as an orphan. Nothing would automatically prevent the other
353 hosts from using the newly allocated PV and corrupting it. If the
354 other hosts run a command to rescan devices, and update lvmetad, they
355 would then recognize that the PV has been used by another host. A com‐
356 mand that rescans devices could be pvscan --cache, or vgs --foreign.
357
360 vgcreate(8), vgchange(8), vgimport(8), vgexport(8), vgs(8), lvm‐
361 lockd(8), lvm.conf(5), machine-id(5), uname(2)
362Red Hat, Inc LVM TOOLS 2.02.180(2)-RHEL7 (2018-07-20) LVMSYSTEMID(7)