1LVMSYSTEMID(7) LVMSYSTEMID(7)
2
6 lvmsystemid — LVM system ID
7
10 Local VGs may exist on shared storage where they are visible to multi‐
11 ple hosts. These VGs are intended to be used by only a single machine,
12 even though they are visible to many. A system_id identifying a single
13 host can be assigned to a VG to indicate the VGs owner. The VG owner
14 can use the VG as usual, and all other hosts will ignore it. This pro‐
15 tects the VG from accidental use by other hosts.
16 The system_id is not a dynamic property, and can only be changed in
18 very limited circumstances (see vgexport and vgimport). Even limited
19 changes to the VG system_id are not perfectly reflected across hosts.
20 A more coherent view of shared storage requires using an inter-host
21 locking system to coordinate access and update caches.
22 The system_id is a string uniquely identifying a host. It can be manu‐
24 ally set to a custom value or it can be assigned automatically by lvm
25 using a unique identifier already available on the host, e.g. machine-
26 id or uname.
27 In vgcreate, the local system_id is saved in the new VG metadata. The
29 local host owns the new VG, and other hosts cannot use it.
30 A VG without a system_id can be used by any host, and a VG with a sys‐
32 tem_id can only be used by a host with a matching system_id. A foreign
33 VG is a VG with a system_id as viewed by a host with a system_id that
34 does not match the VGs system_id. (Or from a host without a sys‐
35 tem_id.)
36 Valid system_id characters are the same as valid VG name characters.
38 If a system_id contains invalid characters, those characters are omit‐
39 ted and remaining characters are used. If a system_id is longer than
40 the maximum name length, the characters up to the maximum length are
41 used. The maximum length of a system_id is 128 characters.
42 Limitations and warnings
45 To benefit fully from system_id, all hosts must have system_id set, and
46 VGs must have system_id set. A VG on shared storage can be damaged or
47 destroyed in some cases which the user must be careful to avoid.
48 · A VG without a system_id can be used without restriction from any
51 host, even from hosts that have a system_id. Many VGs will not have
52 a system_id and are unprotected. Verify that a VG has a system_id by
53 running the command 'vgs -o+systemid'
54 A VG will not have a system_id if it was created before this feature
56 was added to lvm, or if it was created by a host that did not have a
57 system_id defined. A system_id can be assigned to these VGs by using
58 vgchange --systemid (see below).
59 · Two hosts should not be assigned the same system_id. Doing so
62 defeats the purpose of the system_id which is to distinguish differ‐
63 ent hosts.
64 · Orphan PVs (or unused devices) on shared storage are completely
67 unprotected by the system_id feature. Commands that use these PVs,
68 such as vgcreate or vgextend, are not prevented from performing con‐
69 flicting operations and corrupting the PVs. See the orphans section
70 for more information.
71 · A host using an old version of lvm without the system_id feature will
74 not recognize a new system_id in VGs from other hosts. Even though
75 the old version of lvm is not blocked from reading a VG with a sys‐
76 tem_id, it is blocked from writing to the VG (or its LVs). The new
77 system_id changes the write mode of a VG, making it appear read-only
78 to previous lvm versions.
79 This also means that if a host downgrades its version of lvm, it
81 would lose access to any VGs it had created with a system_id. To
82 avoid this, the system_id should be removed from VGs before downgrad‐
83 ing to an lvm version without the system_id feature.
84 Types of VG access
87 A local VG is meant to be used by a single host.
88 A shared or clustered VG is meant to be used by multiple hosts.
89 These can be further distinguished as:
90 Unrestricted: A local VG that has no system_id. This VG type is unpro‐
92 tected and accessible to any host.
93 Owned: A local VG that has a system_id set, as viewed from the one host
95 with a matching system_id (the owner). This VG type is by definition
96 acessible.
97 Foreign: A local VG that has a system_id set, as viewed from any host
99 with an unmatching system_id (or no system_id). It is owned by another
100 host. This VG type is by definition not accessible.
101 Exported: A local VG that has been exported with vgexport and has no
103 system_id. This VG type can only be accessed by vgimport which will
104 change it to owned.
105 Shared: A shared or "lockd" VG has lock_type set and no system_id. A
107 shared VG is meant to be used on shared storage from multiple hosts,
108 and is only accessible to hosts using lvmlockd. Applicable only if LVM
109 is compiled with lockd support.
110 Clustered: A clustered or "clvm" VG has the clustered flag set and no
112 system_id. A clustered VG is meant to be used on shared storage from
113 multiple hosts, and is only accessible to hosts using clvmd.
114 system_id_source
117 A host's own system_id can be defined in a number of ways. lvm.conf
118 global/system_id_source defines the method lvm will use to find the
119 local system_id:
120 none
123 lvm will not use a system_id. lvm is allowed to access VGs
125 without a system_id, and will create new VGs without a sys‐
126 tem_id. An undefined system_id_source is equivalent to none.
127 lvm.conf
129 global {
130 system_id_source = "none"
131 }
132 machineid
135 The content of /etc/machine-id is used as the system_id if
137 available. See machine-id(5) and systemd-machine-id-setup(1) to
138 check if machine-id is available on the host.
139 lvm.conf
141 global {
142 system_id_source = "machineid"
143 }
144 uname
147 The string utsname.nodename from uname(2) is used as the sys‐
149 tem_id. A uname beginning with "localhost" is ignored and
150 equivalent to none.
151 lvm.conf
153 global {
154 system_id_source = "uname"
155 }
156 lvmlocal
159 The system_id is defined in lvmlocal.conf local/system_id.
161 lvm.conf
163 global {
164 system_id_source = "lvmlocal"
165 }
166 lvmlocal.conf
168 local {
169 system_id = "example_name"
170 }
171 file
174 The system_id is defined in a file specified by lvm.conf
176 global/system_id_file.
177 lvm.conf
179 global {
180 system_id_source = "file"
181 system_id_file = "/path/to/file"
182 }
183 Changing system_id_source will often cause the system_id to change,
186 which may prevent the host from using VGs that it previously used (see
187 extra_system_ids below to handle this.)
188 If a system_id_source other than none fails to resolve a system_id, the
190 host will be allowed to access VGs with no system_id, but will not be
191 allowed to access VGs with a defined system_id.
192 extra_system_ids
195 In some cases, it may be useful for a host to access VGs with different
196 system_id's, e.g. if a host's system_id changes, and it wants to use
197 VGs that it created with its old system_id. To allow a host to access
198 VGs with other system_id's, those other system_id's can be listed in
199 lvmlocal.conf local/extra_system_ids.
200 lvmlocal.conf
202 local {
203 extra_system_ids = [ "my_other_name" ]
204 }
205 vgcreate
208 In vgcreate, the host running the command assigns its own system_id to
209 the new VG. To override this and set another system_id:
210 vgcreate --systemid SystemID VG Devices
212 Overriding the system_id makes it possible for a host to create a VG
214 that it may not be able to use. Another host with a system_id matching
215 the one specified may not recognize the new VG without manually rescan‐
216 ning devices.
217 If the --systemid argument is an empty string (""), the VG is created
219 with no system_id, making it accessible to other hosts (see warnings
220 above.)
221 report/display
224 The system_id of a VG is displayed with the "systemid" reporting
225 option.
226 Report/display commands ignore foreign VGs by default. To report for‐
228 eign VGs, the --foreign option can be used. This causes the VGs to be
229 read from disk. Because lvmetad caching is not used, this option can
230 cause poor performance.
231 vgs --foreign -o+systemid
233 When a host with no system_id sees foreign VGs, it warns about them as
235 they are skipped. The host should be assigned a system_id, after which
236 standard reporting commands will silently ignore foreign VGs.
237 vgexport/vgimport
240 vgexport clears the system_id.
241 Other hosts will continue to see a newly exported VG as foreign because
243 of local caching (when lvmetad is used). Manually updating the local
244 lvmetad cache with pvscan --cache will allow a host to recognize the
245 newly exported VG.
246 vgimport sets the VG system_id to the local system_id as determined by
248 lvm.conf system_id_source. vgimport automatically scans storage for
249 newly exported VGs.
250 After vgimport, the exporting host will continue to see the VG as
252 exported, and not owned by the new host. Manually updating the local
253 cache with pvscan --cache will allow a host to recognize the newly
254 imported VG as foreign.
255 vgchange
258 A host can change the system_id of its own VGs, but the command
259 requires confirmation because the host may lose access to the VG being
260 changed:
261 vgchange --systemid SystemID VG
263 The system_id can be removed from a VG by specifying an empty string
265 ("") as the new system_id. This makes the VG accessible to other hosts
266 (see warnings above.)
267 A host cannot directly change the system_id of a foreign VG.
269 To move a VG from one host to another, vgexport and vgimport should be
271 used.
272 To forcibly gain ownership of a foreign VG, a host can add the foreign
274 system_id to its extra_system_ids list, change the system_id of the
275 foreign VG to its own, and remove the foreign system_id from its
276 extra_system_ids list.
277 shared VGs
280 A shared/lockd VG has no system_id set, allowing multiple hosts to use
281 it via lvmlockd. Changing a VG to a lockd type will clear the existing
282 system_id. Applicable only if LVM is compiled with lockd support.
283 clustered VGs
286 A clustered/clvm VG has no system_id set, allowing multiple hosts to
287 use it via clvmd. Changing a VG to clustered will clear the existing
288 system_id. Changing a VG to not clustered will set the system_id to
289 the host running the vgchange command.
290 creation_host
293 In vgcreate, the VG metadata field creation_host is set by default to
294 the host's uname. The creation_host cannot be changed, and is not used
295 to control access. When system_id_source is "uname", the system_id and
296 creation_host will be the same.
297 orphans
300 Orphan PVs are unused devices; they are not currently used in any VG.
301 Because of this, they are not protected by a system_id, and any host
302 can use them. Coordination of changes to orphan PVs is beyond the
303 scope of system_id. The same is true of any block device that is not a
304 PV.
305 The effects of this are especially evident when lvm uses lvmetad
307 caching. For example, if multiple hosts see an orphan PV, and one host
308 creates a VG using the orphan, the other hosts will continue to report
309 the PV as an orphan. Nothing would automatically prevent the other
310 hosts from using the newly allocated PV and corrupting it. If the
311 other hosts run a command to rescan devices, and update lvmetad, they
312 would then recognize that the PV has been used by another host. A com‐
313 mand that rescans devices could be pvscan --cache, or vgs --foreign.
314
317 vgcreate(8), vgchange(8), vgimport(8), vgexport(8), lvm.conf(5),
318 machine-id(5), uname(2), vgs(8)
319Red Hat, Inc LVM TOOLS 2.02.143(2)-RHEL6 (2016-12-13) LVMSYSTEMID(7)