{
    "mode": "info",
    "parameter": "lvmsystemid",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/lvmsystemid/json",
    "generated": "2026-07-06T02:03:22Z",
    "sections": {
        "NAME": {
            "content": "lvmsystemid -- LVM system ID\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The  lvm(8)  system  ID restricts Volume Group (VG) access to one host.\nThis is useful when a VG is placed on shared storage devices,  or  when\nlocal devices are visible to both host and guest operating systems.  In\ncases like these, a VG can be visible to multiple hosts  at  once,  and\nsome mechanism is needed to protect it from being used by more than one\nhost at a time.\n\nA VG's system ID identifies one host as the VG owner.  The host with  a\nmatching system ID can use the VG and its LVs, while LVM on other hosts\nwill ignore it.  This protects the VG from being accidentally used from\nother hosts.\n\nThe  system  ID is a string that uniquely identifies a host.  It can be\nconfigured as a custom value, or it can be  assigned  automatically  by\nLVM  using  some  unique identifier already available on the host, e.g.\nmachine-id or uname.\n\nWhen a new VG is created, the system ID of the local host  is  recorded\nin the VG metadata.  The creating host then owns the new VG, and LVM on\nother hosts will ignore it.  When an existing, exported VG is  imported\n(vgimport),  the  system  ID of the local host is saved in the VG meta-\ndata, 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\ndevices  are  visible.   When  system  IDs are not used, device filters\nshould be configured on all hosts to exclude the VG's devices from  all\nbut one host.\n\nA  foreign VG is a VG seen by a host with an unmatching system ID, i.e.\nthe system ID in the VG metadata does not match the system  ID  config-\nured  on  the host.  If the host has no system ID, and the VG does, the\nVG is foreign and LVM will ignore it.  If the VG has no system ID,  ac-\ncess  is unrestricted, and LVM can access it from any host, whether the\nhost has a system ID or not.\n\nChanges to a host's system ID and a VG's system ID can be made in  lim-\nited  circumstances  (see vgexport and vgimport).  Improper changes can\nresult in a host losing access to its VG, or a  VG  being  accidentally\ndamaged by access from an unintended host.  Even limited changes to the\nVG system ID may not be perfectly reflected across hosts.  A  more  co-\nherent  view of shared storage requires an inter-host locking system to\ncoordinate access.\n\nValid system ID characters are the same as valid  VG  name  characters.\nIf  a system ID contains invalid characters, those characters are omit-\nted and remaining characters are used.  If a system ID is  longer  than\nthe  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\nlvm systemid\n\nLimitations and warnings\nTo benefit fully from system ID, all hosts should have a system ID con-\nfigured,  and  all VGs should have a system ID set.  Without any method\nto restrict access, e.g. system ID or device filters, a VG that is vis-\nible to multiple hosts can be accidentally damaged or destroyed.\n\no A  VG  without  a  system ID can be used without restriction from any\nhost where it is visible, even from hosts that have a system ID.\n\no Many VGs will not have a system ID set because LVM has not enabled it\nby  default,  and even when enabled, many VGs were created before the\nfeature was added to LVM or enabled.  A system ID can be assigned  to\nthese VGs by using vgchange --systemid (see below).\n\no Two  hosts  should  not be assigned the same system ID.  Doing so de-\nfeats the purpose of distinguishing different hosts with this value.\n\no Orphan PVs (or unused devices) on shared storage are  unprotected  by\nthe system ID feature.  Commands that use these PVs, such as vgcreate\nor vgextend, are not prevented from performing conflicting operations\nand  corrupting  the  PVs.  See the orphans section for more informa-\ntion.\n\no The system ID does not protect devices in a VG  from  programs  other\nthan LVM.\n\no A  host using an old LVM version (without the system ID feature) will\nnot recognize a system ID set in VGs.  The old LVM can read a VG with\na  system  ID,  but is prevented from writing to the VG (or its LVs).\nThe system ID feature changes the write mode of a VG, making  it  ap-\npear read-only to previous versions of LVM.\n\nThis  also means that if a host downgrades to the old LVM version, it\nwould lose access to any VGs it had created with  a  system  ID.   To\navoid  this,  the  system  ID should be removed from local VGs before\ndowngrading LVM to a version without the system ID feature.\n\nTypes of VG access\nA 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\nUnrestricted: A local VG that has no system ID.  This VG type is unpro-\ntected and accessible to any host.\n\nOwned:  A  local  VG  that has a system ID set, as viewed from the host\nwith a matching system ID (the owner).  This VG type  is  acessible  to\nthe host.\n\nForeign:  A  local VG that has a system ID set, as viewed from any host\nwith an unmatching system ID (or no system ID).  It is owned by another\nhost.  This VG type is not accessible to the host.\n\nExported:  A  local  VG that has been exported with vgexport and has no\nsystem ID.  This VG type can only be accessed by  vgimport  which  will\nchange it to owned.\n\nShared:  A shared or \"lockd\" VG has the locktype set and has no system\nID.  A shared VG is meant to be used on shared  storage  from  multiple\nhosts,  and is only accessible to hosts using lvmlockd. Applicable only\nif LVM is compiled with lvmlockd support.\n\nClustered: A clustered or \"clvm\" VG has the clustered flag set and  has\nno  system  ID.   A  clustered VG is meant to be used on shared storage\nfrom multiple hosts, and is only accessible to hosts using  clvmd.  Ap-\nplicable only if LVM is compiled with clvm support.\n\nHost system ID configuration\nA  host's  own  system ID can be defined in a number of ways.  lvm.conf\nglobal/systemidsource defines the method LVM will use to find the lo-\ncal system ID:\n\nnone\n\nLVM  will  not  use  a  system ID.  LVM is allowed to access VGs\nwithout a system ID, and will create new VGs  without  a  system\nID.  An undefined systemidsource is equivalent to none.\n\nlvm.conf\nglobal {\nsystemidsource = \"none\"\n}\n\nmachineid\n\nThe  content  of  /etc/machine-id  is  used  as the system ID if\navailable.  See machine-id(5) and systemd-machine-id-setup(1) to\ncheck if machine-id is available on the host.\n\nlvm.conf\nglobal {\nsystemidsource = \"machineid\"\n}\n\nuname\n\nThe  string utsname.nodename from uname(2) is used as the system\nID.  A uname beginning with \"localhost\" is ignored  and  equiva-\nlent to none.\n\nlvm.conf\nglobal {\nsystemidsource = \"uname\"\n}\n\nlvmlocal\n\nThe system ID is defined in lvmlocal.conf local/systemid.\n\nlvm.conf\nglobal {\nsystemidsource = \"lvmlocal\"\n}\n\nlvmlocal.conf\nlocal {\nsystemid = \"examplename\"\n}\n\nfile\n\nThe  system  ID  is  defined  in  a  file  specified by lvm.conf\nglobal/systemidfile.\n\nlvm.conf\nglobal {\nsystemidsource = \"file\"\nsystemidfile = \"/path/to/file\"\n}\n\nChanging systemidsource will likely cause the system ID of  the  host\nto  change,  which  will prevent the host from using VGs that it previ-\nously used (see extrasystemids below to handle this.)\n\nIf a systemidsource other than none fails  to  produce  a  system  ID\nvalue,  it  is the equivalent of having none.  The host will be allowed\nto access VGs with no system ID, but will not be allowed to access  VGs\nwith a system ID set.\n\nOverriding system ID\nIn  some  cases, it may be necessary for a host to access VGs with dif-\nferent system IDs, e.g. if a host's system ID changes, and it wants  to\nuse VGs that it created with its old system ID.  To allow a host to ac-\ncess VGs with other system IDs, those other system IDs can be listed in\nlvmlocal.conf local/extrasystemids.\n\nlvmlocal.conf\nlocal {\nextrasystemids = [ \"myothername\" ]\n}\n\nA  safer  option  may  be configuring the extra values as needed on the\ncommand line as:\n--config 'local/extrasystemids=[\"id\"]'\n\nvgcreate\nIn vgcreate, the host running the command assigns its own system ID  to\nthe new VG.  To override 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\na VG that it may not be able to use.  Another host  with  a  system  ID\nmatching  the  one specified may not recognize the new VG without manu-\nally rescanning devices.\n\nIf the --systemid argument is an empty string (\"\"), the VG  is  created\nwith  no  system  ID, making it accessible to other hosts (see warnings\nabove.)\n\nreport/display\nThe system ID of a VG is displayed with the  \"systemid\"  reporting  op-\ntion.\n\nReport/display  commands ignore foreign VGs by default.  To report for-\neign VGs, the --foreign option can be used.  This causes the VGs to  be\nread from disk.\n\nvgs --foreign -o +systemid\n\nWhen  a host with no system ID sees foreign VGs, it warns about them as\nthey are skipped.  The host should be assigned a system ID, after which\nstandard reporting commands will silently ignore foreign VGs.\n\nvgexport/vgimport\nvgexport 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\nimport.\n\nvgchange\nA host can change the system ID of its own VGs,  but  the  command  re-\nquires  confirmation  because  the host may lose access to the VG being\nchanged:\n\nvgchange --systemid SystemID VG\n\nThe system ID can be removed from a VG by specifying  an  empty  string\n(\"\") as the new system ID.  This makes the VG accessible to other hosts\n(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\nused.\n\nTo  forcibly gain ownership of a foreign VG, a host can temporarily add\nthe foreign system ID to its extrasystemids list, and change the sys-\ntem ID of the foreign VG to its own.  See Overriding system ID above.\n\nshared VGs\nA shared VG has no system ID set, allowing multiple hosts to use it via\nlvmlockd.  Changing a VG to shared will clear the existing  system  ID.\nApplicable only if LVM is compiled with lvmlockd support.\n\nclustered VGs\nA  clustered/clvm  VG  has no system ID set, allowing multiple hosts to\nuse it via clvmd.  Changing a VG to clustered will clear  the  existing\nsystem  ID.   Changing  a VG to not clustered will set the system ID to\nthe host running the vgchange command.\n\ncreationhost\nIn vgcreate, the VG metadata field creationhost is set by  default  to\nthe host's uname.  The creationhost cannot be changed, and is not used\nto control access.  When systemidsource is \"uname\", the systemid and\ncreationhost fields will be the same.\n\norphans\nOrphan  PVs  are unused devices; they are not currently used in any VG.\nBecause of this, they are not protected by a system ID,  and  any  host\ncan  use  them.   Coordination  of  changes to orphan PVs is beyond the\nscope of system ID.  The same is true of any block device that is not a\nPV.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "vgcreate(8),   vgchange(8),   vgimport(8),  vgexport(8),  vgs(8),  lvm-\nlockd(8), lvm.conf(5), machine-id(5), uname(2)\n\nRed Hat, Inc           LVM TOOLS 2.03.11(2) (2021-01-08)        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": "lockd",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/lockd/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"
        }
    ]
}