{
    "mode": "man",
    "parameter": "LVMSYSTEMID",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/man/LVMSYSTEMID/json",
    "generated": "2026-10-22T13:28:20Z",
    "sections": {
        "NAME": {
            "content": "lvmsystemid — LVM system ID\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The  lvm(8)  system ID restricts Volume Group (VG) access to one host.  This is useful when a\nVG is placed on shared storage devices, or when local devices are visible to  both  host  and\nguest operating systems.  In cases like these, a VG can be visible to multiple hosts at once,\nand some mechanism is needed to protect it from being used by more than one host at a time.\n\nA VG's system ID identifies one host as the VG owner.  The host with a matching system ID can\nuse  the  VG and its LVs, while LVM on other hosts will ignore it.  This protects the VG from\nbeing accidentally used from other hosts.\n\nThe system ID is a string that uniquely identifies a host.  It can be configured as a  custom\nvalue, or it can be assigned automatically by LVM using some unique identifier already avail‐\nable on the host, e.g.  machine-id or uname.\n\nWhen  a  new  VG  is created, the system ID of the local host is recorded in the VG metadata.\nThe creating host then owns the new VG, and LVM on other hosts will ignore it.  When  an  ex‐\nisting,  exported  VG is imported (vgimport), the system ID of the local host is saved in the\nVG metadata, and the importing host owns the VG.\n\nA VG without a system ID can be used by LVM on any host where the VG's devices  are  visible.\nWhen system IDs are not used, device filters should be configured on all hosts to exclude the\nVG's devices from all but one host.\n\nA  foreign  VG is a VG seen by a host with an unmatching system ID, i.e. the system ID in the\nVG metadata does not match the system ID configured on the host.  If the host has  no  system\nID,  and  the VG does, the VG is foreign and LVM will ignore it.  If the VG has no system ID,\naccess is unrestricted, and LVM can access it from any host, whether the host has a system ID\nor not.\n\nChanges to a host's system ID and a VG's system ID can be made in limited circumstances  (see\nvgexport  and vgimport).  Improper changes can result in a host losing access to its VG, or a\nVG being accidentally damaged by access from an unintended host.  Even limited changes to the\nVG system ID may not be perfectly reflected across hosts.  A more  coherent  view  of  shared\nstorage requires an inter-host locking system to coordinate access.\n\nValid system ID characters are the same as valid VG name characters.  If a system ID contains\ninvalid  characters,  those  characters  are omitted and remaining characters are used.  If a\nsystem ID is longer than the maximum name length, the characters up to the maximum length are\nused.  The maximum length of a system ID is 128 characters.\n\nPrint the system ID of a VG to check if it is set:\n\nvgs -o systemid VG\n\nPrint the system ID of the local host to check if it is configured:\n",
            "subsections": [
                {
                    "name": "lvm systemid",
                    "content": ""
                },
                {
                    "name": "Limitations and warnings",
                    "content": "To benefit fully from system ID, all hosts should have a system ID configured,  and  all  VGs\nshould have a system ID set.  Without any method to restrict access, e.g. system ID or device\nfilters, a VG that is visible to multiple hosts can be accidentally damaged or destroyed.\n\n• A VG without a system ID can be used without restriction from any host where it is visible,\neven from hosts that have a system ID.\n\n• Many  VGs will not have a system ID set because LVM has not enabled it by default, and even\nwhen enabled, many VGs were created before the feature was added to LVM or enabled.  A sys‐\ntem ID can be assigned to these VGs by using vgchange --systemid (see below).\n\n• Two hosts should not be assigned the same system ID.  Doing so defeats the purpose of  dis‐\ntinguishing different hosts with this value.\n\n• Orphan  PVs (or unused devices) on shared storage are unprotected by the system ID feature.\nCommands that use these PVs, such as vgcreate or vgextend, are not prevented from  perform‐\ning conflicting operations and corrupting the PVs.  See the orphans section for more infor‐\nmation.\n\n• The system ID does not protect devices in a VG from programs other than LVM.\n\n• A host using an old LVM version (without the system ID feature) will not recognize a system\nID  set  in VGs.  The old LVM can read a VG with a system ID, but is prevented from writing\nto the VG (or its LVs).  The system ID feature changes the write mode of a  VG,  making  it\nappear read-only to previous versions of LVM.\n\nThis  also  means that if a host downgrades to the old LVM version, it would lose access to\nany VGs it had created with a system ID.  To avoid this, the system ID  should  be  removed\nfrom local VGs before downgrading LVM to a version without the system ID feature.\n"
                },
                {
                    "name": "Types of VG access",
                    "content": "A local VG is meant to be used by a single host.\n\nA shared or clustered VG is meant to be used by multiple hosts.\n\nThese can be further distinguished as:\n"
                },
                {
                    "name": "Unrestricted:",
                    "content": "A  local  VG that has no system ID.  This VG type is unprotected and accessible to any\nhost.\n\nOwned: A local VG that has a system ID set, as viewed from the host with a matching system ID\n(the owner).  This VG type is accessible to the host.\n"
                },
                {
                    "name": "Foreign:",
                    "content": "A local VG that has a system ID set, as viewed from any host with an unmatching system\nID (or no system ID).  It is owned by another host.  This VG type is not accessible to\nthe host.\n"
                },
                {
                    "name": "Exported:",
                    "content": "A local VG that has been exported with vgexport and has no system ID.   This  VG  type\ncan only be accessed by vgimport which will change it to owned.\n"
                },
                {
                    "name": "Shared:",
                    "content": "A  shared  or  \"lockd\"  VG has the locktype set and has no system ID.  A shared VG is\nmeant to be used on shared storage from multiple hosts,  and  is  only  accessible  to\nhosts using lvmlockd. Applicable only if LVM is compiled with lvmlockd support.\n"
                },
                {
                    "name": "Clustered:",
                    "content": "A clustered or \"clvm\" VG has the clustered flag set and has no system ID.  A clustered\nVG  is  meant to be used on shared storage from multiple hosts, and is only accessible\nto hosts using clvmd. Applicable only if LVM is compiled with clvm support.\n"
                },
                {
                    "name": "Host system ID configuration",
                    "content": "A host's own system ID can be defined in a number of ways.  lvm.conf  global/systemidsource\ndefines the method LVM will use to find the local system ID:\n"
                },
                {
                    "name": "none",
                    "content": "LVM  will  not use a system ID.  LVM is allowed to access VGs without a system ID, and\nwill create new VGs without a system ID.  An undefined systemidsource is  equivalent\nto none.\n\nlvm.conf\nglobal {\nsystemidsource = \"none\"\n}\n"
                },
                {
                    "name": "appmachineid",
                    "content": "An  LVM-specific  derivation  of  /etc/machine-id  is  used as the system ID.  See ma‐\nchine-id(5) to check if machine-id is available on the host.\n\nlvm.conf\nglobal {\nsystemidsource = \"appmachineid\"\n}\n\n"
                },
                {
                    "name": "machineid",
                    "content": "The content of /etc/machine-id is used  as  the  system  ID  if  available.   See  ma‐\nchine-id(5) and systemd-machine-id-setup(1) to check if machine-id is available on the\nhost.  (appmachineid is recommended in place of machineid.)\n\nlvm.conf\nglobal {\nsystemidsource = \"machineid\"\n}\n"
                },
                {
                    "name": "uname",
                    "content": "The string utsname.nodename from uname(2) is used as the system ID.  A uname beginning\nwith \"localhost\" is ignored and equivalent to none.\n\nlvm.conf\nglobal {\nsystemidsource = \"uname\"\n}\n"
                },
                {
                    "name": "lvmlocal",
                    "content": "The system ID is defined in lvmlocal.conf local/systemid.\n\nlvm.conf\nglobal {\nsystemidsource = \"lvmlocal\"\n}\n\nlvmlocal.conf\nlocal {\nsystemid = \"examplename\"\n}\n"
                },
                {
                    "name": "file",
                    "content": "The system ID is defined in a file specified by lvm.conf global/systemidfile.\n\nlvm.conf\nglobal {\nsystemidsource = \"file\"\nsystemidfile = \"/path/to/file\"\n}\n\nChanging  systemidsource  will likely cause the system ID of the host to change, which will\nprevent the host from using VGs that it previously used (see extrasystemids below to handle\nthis.)\n\nIf a systemidsource other than none fails to produce a system ID value, it is  the  equiva‐\nlent  of having none.  The host will be allowed to access VGs with no system ID, but will not\nbe allowed to access VGs with a system ID set.\n"
                },
                {
                    "name": "Overriding system ID",
                    "content": "In some cases, it may be necessary for a host to access VGs with different system  IDs,  e.g.\nif  a  host's  system ID changes, and it wants to use VGs that it created with its old system\nID.  To allow a host to access VGs with other system IDs,  those  other  system  IDs  can  be\nlisted in lvmlocal.conf local/extrasystemids.\n\nlvmlocal.conf\nlocal {\nextrasystemids = [ \"myothername\" ]\n}\n\nA safer option may be configuring the extra values as needed on the command line as:\n--config 'local/extrasystemids=[\"id\"]'\n"
                },
                {
                    "name": "vgcreate",
                    "content": "In  vgcreate, the host running the command assigns its own system ID to the new VG.  To over‐\nride this and set another system ID:\n\nvgcreate --systemid SystemID VG PVs\n\nOverriding the host's system ID makes it possible for a host to create a VG that it  may  not\nbe  able  to use.  Another host with a system ID matching the one specified may not recognize\nthe new VG without manually rescanning devices.\n\nIf the --systemid argument is an empty string (\"\"), the VG is created with no system ID, mak‐\ning it accessible to other hosts (see warnings above.)\n"
                },
                {
                    "name": "report/display",
                    "content": "The system ID of a VG is displayed with the \"systemid\" reporting option.\n\nReport/display commands ignore foreign VGs by default.  To report foreign VGs, the  --foreign\noption can be used.  This causes the VGs to be read from disk.\n"
                },
                {
                    "name": "vgs --foreign -o +systemid",
                    "content": "When a host with no system ID sees foreign VGs, it warns about them as they are skipped.  The\nhost  should  be  assigned a system ID, after which standard reporting commands will silently\nignore foreign VGs.\n"
                },
                {
                    "name": "vgexport/vgimport",
                    "content": "vgexport clears the VG system ID when exporting the VG.\n\nvgimport sets the VG system ID to the system ID of the host doing the import.\n"
                },
                {
                    "name": "vgchange",
                    "content": "A host can change the system ID of its own VGs, but the command requires confirmation because\nthe host may lose access to the VG being changed:\n\nvgchange --systemid SystemID VG\n\nThe system ID can be removed from a VG by specifying an empty string (\"\") as the  new  system\nID.  This makes the VG accessible to other hosts (see warnings above.)\n\nA host cannot directly change the system ID of a foreign VG.\n\nTo move a VG from one host to another, vgexport and vgimport should be used.\n\nTo  forcibly gain ownership of a foreign VG, a host can temporarily add the foreign system ID\nto its extrasystemids list, and change the system ID of the foreign VG  to  its  own.   See\nOverriding system ID above.\n"
                },
                {
                    "name": "shared VGs",
                    "content": "A shared VG has no system ID set, allowing multiple hosts to use it via lvmlockd.  Changing a\nVG to shared will clear the existing system ID.  Applicable only if LVM is compiled with lvm‐\nlockd support.\n"
                },
                {
                    "name": "clustered VGs",
                    "content": "A  clustered/clvm  VG  has  no  system  ID  set, allowing multiple hosts to use it via clvmd.\nChanging a VG to clustered will clear the existing system ID.  Changing a VG to not clustered\nwill set the system ID to the host running the vgchange command.\n"
                },
                {
                    "name": "creation_host",
                    "content": "In vgcreate, the VG metadata field creationhost is set by default to the host's uname.   The\ncreationhost cannot be changed, and is not used to control access.  When systemidsource is\n\"uname\", the systemid and creationhost fields will be the same.\n"
                },
                {
                    "name": "orphans",
                    "content": "Orphan  PVs are unused devices; they are not currently used in any VG.  Because of this, they\nare not protected by a system ID, and any host can use them.  Coordination of changes to  or‐\nphan  PVs is beyond the scope of system ID.  The same is true of any block device that is not\na PV.\n"
                }
            ]
        },
        "SEE ALSO": {
            "content": "vgcreate(8), vgchange(8), vgimport(8), vgexport(8), vgs(8), lvmlockd(8), lvm.conf(5),\nmachine-id(5), uname(2)\n\nRed Hat, Inc                      LVM TOOLS 2.03.16(2) (2022-05-18)                   LVMSYSTEMID(7)",
            "subsections": []
        }
    },
    "summary": "lvmsystemid — LVM system ID",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "vgcreate",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/vgcreate/8/json"
        },
        {
            "name": "vgchange",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/vgchange/8/json"
        },
        {
            "name": "vgimport",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/vgimport/8/json"
        },
        {
            "name": "vgexport",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/vgexport/8/json"
        },
        {
            "name": "vgs",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/vgs/8/json"
        },
        {
            "name": "lvmlockd",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/lvmlockd/8/json"
        },
        {
            "name": "lvm.conf",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/lvm.conf/5/json"
        },
        {
            "name": "machine-id",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/machine-id/5/json"
        },
        {
            "name": "uname",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/uname/2/json"
        }
    ]
}