[Users] Old storage domain ID left behind in master storage domain's metadata
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8Qf0tsilRDVmNDemCrWbW5SFPEiBh91w5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I started with an all-in-one installation of ovirt 3.3.2 on a FC19 host. After the initial setup was done, I created a new datacenter, cluster and storage domain in the engine and moved the single host in the engine to the new cluster. After that I deleted the automatically created storage domain, local datacenter, etc. It seems, however, that the new master storage domain still contains some references to the now removed old storage domains in its metadata. Here's the metadata, extracted from the tags of the VG. I got them using vgs: MDT_DESCRIPTION=3DStorageDomainX MDT_LOCKPOLICY=3D MDT_PV0=3Dpv:36090a098103b1821532d057a5a0120d4&44&uuid:xreVSW-NmjD-MUqk-j= ucQ-Hrbs-KRe8-P93tn3&44&pestart:0&44&pecount:798&44&mapoffset:0 MDT_TYPE=3DISCSI MDT_LOGBLKSIZE=3D512 MDT_VGUUID=3Dnpukh2-ulUm-MEbj-T0TZ-0kDX-pUkp-2hJEKo MDT_LEASERETRIES=3D3 MDT_IOOPTIMEOUTSEC=3D10 MDT_LOCKRENEWALINTERVALSEC=3D5 MDT_SDUUID=3D3307f6fa-dd58-43db-ab23-b1fb299006c7 MDT_PHYBLKSIZE=3D512 MDT_CLASS=3DData MDT_VERSION=3D3 RHAT_storage_domain MDT_POOL_UUID=3D61f15cc0-8bba-482d-8a81-cd636a581b58 MDT_ROLE=3DMaster MDT_MASTER_VERSION=3D44 MDT_POOL_DESCRIPTION=3DDataCenterX MDT_POOL_DOMAINS=3Dec4ba43a-e334-4ce2-90d1-86e5a6da071d:Active&44&a7af75f= e-b96a-4ebe-8903-5743a8176311:Active&44&ff33856e-e00f-4be8-9456-8e47c592f= 82f:Active&44&3307f6fa-dd58-43db-ab23-b1fb299006c7:Active MDT_PV1=3Dpv:36090a09810bb99fefb2da57b94332027&44&uuid:UMUs49-GvEF-IOgZ-p= 6jD-yP1r-dpnd-syawJz&44&pestart:0&44&pecount:798&44&mapoffset:798 MDT_POOL_SPM_ID=3D1 MDT_POOL_SPM_LVER=3D30 MDT__SHA_CKSUM=3Dad43ad855d386b103a672a0801a932a9ee115ed7 Notably, see MDT_POOL_DOMAINS. Domains ec4ba43a-e334-4ce2-90d1-86e5a6da071d and a7af75fe-b96a-4ebe-8903-5743a8176311 no longer exist in the engine (were removed from admin UI). Their presence in the metadata causes vdsmd to repeatedly try to access those domains, resulting in constant error messages in the log that the domains don't exist. Any advice on how to properly clean up the old domains from the metadata?= Thanks in advance! Boyan Tabakov --8Qf0tsilRDVmNDemCrWbW5SFPEiBh91w5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMMd4IACgkQXOXFG4fgV74krACgrCcQ5guCNZksBhBuKVf522kE 9K8AnRT8gFMNlskIQ8iWOjZ2/FscNVmc =nwoJ -----END PGP SIGNATURE----- --8Qf0tsilRDVmNDemCrWbW5SFPEiBh91w5--
Hi, How exactly did you delete the storage domain and dc?
From the steps you are describing, since the host was not part of the DC when you removed it you had to have used 'force remove' on the DC, which does indeed remove the DC and the domain from the UI, but that is *all* it does. It only removes references to those objects from engine's DB, it does not remove the actual storage domain (VG).
Thanks, Gadi Ickowicz ----- Original Message ----- From: "Boyan Tabakov" <blade@alslayer.net> To: users@ovirt.org Sent: Tuesday, February 25, 2014 12:59:09 PM Subject: [Users] Old storage domain ID left behind in master storage domain's metadata Hello, I started with an all-in-one installation of ovirt 3.3.2 on a FC19 host. After the initial setup was done, I created a new datacenter, cluster and storage domain in the engine and moved the single host in the engine to the new cluster. After that I deleted the automatically created storage domain, local datacenter, etc. It seems, however, that the new master storage domain still contains some references to the now removed old storage domains in its metadata. Here's the metadata, extracted from the tags of the VG. I got them using vgs: MDT_DESCRIPTION=StorageDomainX MDT_LOCKPOLICY= MDT_PV0=pv:36090a098103b1821532d057a5a0120d4&44&uuid:xreVSW-NmjD-MUqk-jucQ-Hrbs-KRe8-P93tn3&44&pestart:0&44&pecount:798&44&mapoffset:0 MDT_TYPE=ISCSI MDT_LOGBLKSIZE=512 MDT_VGUUID=npukh2-ulUm-MEbj-T0TZ-0kDX-pUkp-2hJEKo MDT_LEASERETRIES=3 MDT_IOOPTIMEOUTSEC=10 MDT_LOCKRENEWALINTERVALSEC=5 MDT_SDUUID=3307f6fa-dd58-43db-ab23-b1fb299006c7 MDT_PHYBLKSIZE=512 MDT_CLASS=Data MDT_VERSION=3 RHAT_storage_domain MDT_POOL_UUID=61f15cc0-8bba-482d-8a81-cd636a581b58 MDT_ROLE=Master MDT_MASTER_VERSION=44 MDT_POOL_DESCRIPTION=DataCenterX MDT_POOL_DOMAINS=ec4ba43a-e334-4ce2-90d1-86e5a6da071d:Active&44&a7af75fe-b96a-4ebe-8903-5743a8176311:Active&44&ff33856e-e00f-4be8-9456-8e47c592f82f:Active&44&3307f6fa-dd58-43db-ab23-b1fb299006c7:Active MDT_PV1=pv:36090a09810bb99fefb2da57b94332027&44&uuid:UMUs49-GvEF-IOgZ-p6jD-yP1r-dpnd-syawJz&44&pestart:0&44&pecount:798&44&mapoffset:798 MDT_POOL_SPM_ID=1 MDT_POOL_SPM_LVER=30 MDT__SHA_CKSUM=ad43ad855d386b103a672a0801a932a9ee115ed7 Notably, see MDT_POOL_DOMAINS. Domains ec4ba43a-e334-4ce2-90d1-86e5a6da071d and a7af75fe-b96a-4ebe-8903-5743a8176311 no longer exist in the engine (were removed from admin UI). Their presence in the metadata causes vdsmd to repeatedly try to access those domains, resulting in constant error messages in the log that the domains don't exist. Any advice on how to properly clean up the old domains from the metadata? Thanks in advance! Boyan Tabakov _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VxXoEQcaodVE2f9otJ1LlGmtH6UBqmaVH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 25.2.2014, 14:00, Gadi Ickowicz wrote:
Hi, =20 How exactly did you delete the storage domain and dc?=20 =20 From the steps you are describing, since the host was not part of the D= C when you removed it you had to have used 'force remove' on the DC, whic= h does indeed remove the DC and the domain from the UI, but that is *all*= it does.=20 It only removes references to those objects from engine's DB, it does n= ot remove the actual storage domain (VG).
If I recall correctly (that was couple of months ago), I might have really forced the removal. The issue was, that I wanted to get rid of the default created local storage domain and datacenter, so that I can create a proper iSCSI storage domain and later add other nodes (convert the all-in-one to multinode setup). The idea was to convert the all-in-one installation to one having multiple nodes and one of those running the engine. Since in the beginning there was only one host, the all-in-one one, it had to be moved to a new DC. That left the default DC without any host. Was there a better way to achieve this? Is it possible to manually update the metadata or tell vdsmd to do so somehow? Thanks, Boyan --VxXoEQcaodVE2f9otJ1LlGmtH6UBqmaVH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMMj7sACgkQXOXFG4fgV758SgCeI9P1FkJ+3Wt2S4d3whynrMhv YyQAnR1+oggCdq6l9XSTlvNjOQoYQV1e =+9Pt -----END PGP SIGNATURE----- --VxXoEQcaodVE2f9otJ1LlGmtH6UBqmaVH--
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S8TIQhFdvusbHvqnivHho3I5HrXcHoSGa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25.2.2014, 14:42, Boyan Tabakov wrote: > Hi, >=20 > On 25.2.2014, 14:00, Gadi Ickowicz wrote: >> Hi, >> >> How exactly did you delete the storage domain and dc?=20 >> >> From the steps you are describing, since the host was not part of the = DC when you removed it you had to have used 'force remove' on the DC, whi= ch does indeed remove the DC and the domain from the UI, but that is *all= * it does.=20 >> It only removes references to those objects from engine's DB, it does = not remove the actual storage domain (VG). >=20 > If I recall correctly (that was couple of months ago), I might have > really forced the removal. The issue was, that I wanted to get rid of > the default created local storage domain and datacenter, so that I can > create a proper iSCSI storage domain and later add other nodes (convert= > the all-in-one to multinode setup). >=20 > The idea was to convert the all-in-one installation to one having > multiple nodes and one of those running the engine. Since in the > beginning there was only one host, the all-in-one one, it had to be > moved to a new DC. That left the default DC without any host. >=20 > Was there a better way to achieve this? Is it possible to manually > update the metadata or tell vdsmd to do so somehow? >=20 > Thanks, > Boyan >=20 >=20 Additionally, one of the left out domains was a test iSCSI SD created in the new SD, which was removed cleanly, afaik. --S8TIQhFdvusbHvqnivHho3I5HrXcHoSGa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMMkR8ACgkQXOXFG4fgV74qiQCfeYLO++piioL80XAHYQCrhngd vDIAnRrtvppDaDNkEyUBBggfDqmvorg/ =FVx5 -----END PGP SIGNATURE----- --S8TIQhFdvusbHvqnivHho3I5HrXcHoSGa--
Regarding the way to remove the old DC and move from local to iSCSI storage, you can: 1) deactivate the last domain in the DC (After detaching all other domains in the DC) 2) remove the DC (while there is still a host in the DC) 3) remove the domain regularly (which should clean the storage itself 4) move the host to the new DC Regarding the fact that the other domain was removed cleanly and is still visible in the metadata that is very strange. Do you happen to have logs from the creation/deletion of that domain? Gadi Ickowicz ----- Original Message ----- From: "Boyan Tabakov" <blade@alslayer.net> To: "Gadi Ickowicz" <gickowic@redhat.com> Cc: users@ovirt.org Sent: Tuesday, February 25, 2014 2:48:30 PM Subject: Re: [Users] Old storage domain ID left behind in master storage domain's metadata On 25.2.2014, 14:42, Boyan Tabakov wrote:
Hi,
On 25.2.2014, 14:00, Gadi Ickowicz wrote:
Hi,
How exactly did you delete the storage domain and dc?
From the steps you are describing, since the host was not part of the DC when you removed it you had to have used 'force remove' on the DC, which does indeed remove the DC and the domain from the UI, but that is *all* it does. It only removes references to those objects from engine's DB, it does not remove the actual storage domain (VG).
If I recall correctly (that was couple of months ago), I might have really forced the removal. The issue was, that I wanted to get rid of the default created local storage domain and datacenter, so that I can create a proper iSCSI storage domain and later add other nodes (convert the all-in-one to multinode setup).
The idea was to convert the all-in-one installation to one having multiple nodes and one of those running the engine. Since in the beginning there was only one host, the all-in-one one, it had to be moved to a new DC. That left the default DC without any host.
Was there a better way to achieve this? Is it possible to manually update the metadata or tell vdsmd to do so somehow?
Thanks, Boyan
Additionally, one of the left out domains was a test iSCSI SD created in the new SD, which was removed cleanly, afaik.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EAEANRG3dFNofo73LIv5DX70SalGxWBcD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25.2.2014, 15:26, Gadi Ickowicz wrote:
Regarding the way to remove the old DC and move from local to iSCSI sto= rage, you can: 1) deactivate the last domain in the DC (After detaching all other doma= ins in the DC) 2) remove the DC (while there is still a host in the DC) 3) remove the domain regularly (which should clean the storage itself 4) move the host to the new DC
Thanks! Unfortunately I have some production loads already and starting over would be tough. Any pointers on how the metadata can be fixed?
Regarding the fact that the other domain was removed cleanly and is sti= ll visible in the metadata that is very strange. Do you happen to have lo= gs from the creation/deletion of that domain?
Looks like those logs are rotated away already. --EAEANRG3dFNofo73LIv5DX70SalGxWBcD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMMn8AACgkQXOXFG4fgV75yqACgmml/i2f6H63xZKKDObsUP8kD 784AoM8o0FxdE8wU8KtoI+KX4ypA0xjz =0GMt -----END PGP SIGNATURE----- --EAEANRG3dFNofo73LIv5DX70SalGxWBcD--
I am not really sure what the recommended way is (adding Nir Soffer, hopefully he can help or point us to the right person). Maybe you can try manually deactivating and detaching the domains from the pool using vdsClient on the SPM host (for each of the domains): deactivateStorageDomain <domainID> <poolID> detachStorageDomain <domainID> <poolID> if you have vdsm configured for secure connection (default) then you can ssh to the host and run the following command: vdsClient -s 0 [commands from above]. Otherwise you don't need the -s. I guess you already have the domainID (VG name) and the poolID (from the previous mails you sent). Not sure if this is the correct way to solve this problem - Nir? Gadi Ickowicz ----- Original Message ----- From: "Boyan Tabakov" <blade@alslayer.net> To: "Gadi Ickowicz" <gickowic@redhat.com> Cc: users@ovirt.org Sent: Tuesday, February 25, 2014 3:50:42 PM Subject: Re: [Users] Old storage domain ID left behind in master storage domain's metadata On 25.2.2014, 15:26, Gadi Ickowicz wrote:
Regarding the way to remove the old DC and move from local to iSCSI storage, you can: 1) deactivate the last domain in the DC (After detaching all other domains in the DC) 2) remove the DC (while there is still a host in the DC) 3) remove the domain regularly (which should clean the storage itself 4) move the host to the new DC
Thanks! Unfortunately I have some production loads already and starting over would be tough. Any pointers on how the metadata can be fixed?
Regarding the fact that the other domain was removed cleanly and is still visible in the metadata that is very strange. Do you happen to have logs from the creation/deletion of that domain?
Looks like those logs are rotated away already.
How exactly did you remove the old local storage domain? ----- Original Message ----- From: "Boyan Tabakov" <blade@alslayer.net> To: users@ovirt.org Sent: Tuesday, February 25, 2014 12:59:09 PM Subject: [Users] Old storage domain ID left behind in master storage domain's metadata Hello, I started with an all-in-one installation of ovirt 3.3.2 on a FC19 host. After the initial setup was done, I created a new datacenter, cluster and storage domain in the engine and moved the single host in the engine to the new cluster. After that I deleted the automatically created storage domain, local datacenter, etc. It seems, however, that the new master storage domain still contains some references to the now removed old storage domains in its metadata. Here's the metadata, extracted from the tags of the VG. I got them using vgs: MDT_DESCRIPTION=StorageDomainX MDT_LOCKPOLICY= MDT_PV0=pv:36090a098103b1821532d057a5a0120d4&44&uuid:xreVSW-NmjD-MUqk-jucQ-Hrbs-KRe8-P93tn3&44&pestart:0&44&pecount:798&44&mapoffset:0 MDT_TYPE=ISCSI MDT_LOGBLKSIZE=512 MDT_VGUUID=npukh2-ulUm-MEbj-T0TZ-0kDX-pUkp-2hJEKo MDT_LEASERETRIES=3 MDT_IOOPTIMEOUTSEC=10 MDT_LOCKRENEWALINTERVALSEC=5 MDT_SDUUID=3307f6fa-dd58-43db-ab23-b1fb299006c7 MDT_PHYBLKSIZE=512 MDT_CLASS=Data MDT_VERSION=3 RHAT_storage_domain MDT_POOL_UUID=61f15cc0-8bba-482d-8a81-cd636a581b58 MDT_ROLE=Master MDT_MASTER_VERSION=44 MDT_POOL_DESCRIPTION=DataCenterX MDT_POOL_DOMAINS=ec4ba43a-e334-4ce2-90d1-86e5a6da071d:Active&44&a7af75fe-b96a-4ebe-8903-5743a8176311:Active&44&ff33856e-e00f-4be8-9456-8e47c592f82f:Active&44&3307f6fa-dd58-43db-ab23-b1fb299006c7:Active MDT_PV1=pv:36090a09810bb99fefb2da57b94332027&44&uuid:UMUs49-GvEF-IOgZ-p6jD-yP1r-dpnd-syawJz&44&pestart:0&44&pecount:798&44&mapoffset:798 MDT_POOL_SPM_ID=1 MDT_POOL_SPM_LVER=30 MDT__SHA_CKSUM=ad43ad855d386b103a672a0801a932a9ee115ed7 Notably, see MDT_POOL_DOMAINS. Domains ec4ba43a-e334-4ce2-90d1-86e5a6da071d and a7af75fe-b96a-4ebe-8903-5743a8176311 no longer exist in the engine (were removed from admin UI). Their presence in the metadata causes vdsmd to repeatedly try to access those domains, resulting in constant error messages in the log that the domains don't exist. Any advice on how to properly clean up the old domains from the metadata? Thanks in advance! Boyan Tabakov _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- Original Message -----
From: "Boyan Tabakov" <blade@alslayer.net> To: users@ovirt.org Sent: Tuesday, February 25, 2014 12:59:09 PM Subject: [Users] Old storage domain ID left behind in master storage domain's metadata
Hello,
I started with an all-in-one installation of ovirt 3.3.2 on a FC19 host. After the initial setup was done, I created a new datacenter, cluster and storage domain in the engine and moved the single host in the engine to the new cluster. After that I deleted the automatically created storage domain, local datacenter, etc.
It seems, however, that the new master storage domain still contains some references to the now removed old storage domains in its metadata. Here's the metadata, extracted from the tags of the VG. I got them using vgs:
MDT_DESCRIPTION=StorageDomainX MDT_LOCKPOLICY= MDT_PV0=pv:36090a098103b1821532d057a5a0120d4&44&uuid:xreVSW-NmjD-MUqk-jucQ-Hrbs-KRe8-P93tn3&44&pestart:0&44&pecount:798&44&mapoffset:0 MDT_TYPE=ISCSI MDT_LOGBLKSIZE=512 MDT_VGUUID=npukh2-ulUm-MEbj-T0TZ-0kDX-pUkp-2hJEKo MDT_LEASERETRIES=3 MDT_IOOPTIMEOUTSEC=10 MDT_LOCKRENEWALINTERVALSEC=5 MDT_SDUUID=3307f6fa-dd58-43db-ab23-b1fb299006c7 MDT_PHYBLKSIZE=512 MDT_CLASS=Data MDT_VERSION=3 RHAT_storage_domain MDT_POOL_UUID=61f15cc0-8bba-482d-8a81-cd636a581b58 MDT_ROLE=Master MDT_MASTER_VERSION=44 MDT_POOL_DESCRIPTION=DataCenterX MDT_POOL_DOMAINS=ec4ba43a-e334-4ce2-90d1-86e5a6da071d:Active&44&a7af75fe-b96a-4ebe-8903-5743a8176311:Active&44&ff33856e-e00f-4be8-9456-8e47c592f82f:Active&44&3307f6fa-dd58-43db-ab23-b1fb299006c7:Active MDT_PV1=pv:36090a09810bb99fefb2da57b94332027&44&uuid:UMUs49-GvEF-IOgZ-p6jD-yP1r-dpnd-syawJz&44&pestart:0&44&pecount:798&44&mapoffset:798 MDT_POOL_SPM_ID=1 MDT_POOL_SPM_LVER=30 MDT__SHA_CKSUM=ad43ad855d386b103a672a0801a932a9ee115ed7
Notably, see MDT_POOL_DOMAINS. Domains ec4ba43a-e334-4ce2-90d1-86e5a6da071d and a7af75fe-b96a-4ebe-8903-5743a8176311 no longer exist in the engine (were removed from admin UI).
Their presence in the metadata causes vdsmd to repeatedly try to access those domains, resulting in constant error messages in the log that the domains don't exist.
Any advice on how to properly clean up the old domains from the metadata?
The easy way to do this is to use vdsClient tool: vdsClient -s 0 forcedDetachStorageDomain <domain UUID> <pool UUID> If you are not using secure connection (ssl=true), remove the -s option. Nir
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2HL2sI0NmLbAoVBrOEQwsWUMqrns2ElTq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed Feb 26 11:51:18 2014, Nir Soffer wrote:
----- Original Message -----
From: "Boyan Tabakov" <blade@alslayer.net> To: users@ovirt.org Sent: Tuesday, February 25, 2014 12:59:09 PM Subject: [Users] Old storage domain ID left behind in master storage d= omain's metadata
Hello,
I started with an all-in-one installation of ovirt 3.3.2 on a FC19 hos= t. After the initial setup was done, I created a new datacenter, cluster and storage domain in the engine and moved the single host in the engi= ne to the new cluster. After that I deleted the automatically created storage domain, local datacenter, etc.
It seems, however, that the new master storage domain still contains some references to the now removed old storage domains in its metadata= =2E Here's the metadata, extracted from the tags of the VG. I got them usi= ng vgs:
MDT_DESCRIPTION=3DStorageDomainX MDT_LOCKPOLICY=3D MDT_PV0=3Dpv:36090a098103b1821532d057a5a0120d4&44&uuid:xreVSW-NmjD-MUq= k-jucQ-Hrbs-KRe8-P93tn3&44&pestart:0&44&pecount:798&44&mapoffset:0 MDT_TYPE=3DISCSI MDT_LOGBLKSIZE=3D512 MDT_VGUUID=3Dnpukh2-ulUm-MEbj-T0TZ-0kDX-pUkp-2hJEKo MDT_LEASERETRIES=3D3 MDT_IOOPTIMEOUTSEC=3D10 MDT_LOCKRENEWALINTERVALSEC=3D5 MDT_SDUUID=3D3307f6fa-dd58-43db-ab23-b1fb299006c7 MDT_PHYBLKSIZE=3D512 MDT_CLASS=3DData MDT_VERSION=3D3 RHAT_storage_domain MDT_POOL_UUID=3D61f15cc0-8bba-482d-8a81-cd636a581b58 MDT_ROLE=3DMaster MDT_MASTER_VERSION=3D44 MDT_POOL_DESCRIPTION=3DDataCenterX MDT_POOL_DOMAINS=3Dec4ba43a-e334-4ce2-90d1-86e5a6da071d:Active&44&a7af= 75fe-b96a-4ebe-8903-5743a8176311:Active&44&ff33856e-e00f-4be8-9456-8e47c5= 92f82f:Active&44&3307f6fa-dd58-43db-ab23-b1fb299006c7:Active MDT_PV1=3Dpv:36090a09810bb99fefb2da57b94332027&44&uuid:UMUs49-GvEF-IOg= Z-p6jD-yP1r-dpnd-syawJz&44&pestart:0&44&pecount:798&44&mapoffset:798 MDT_POOL_SPM_ID=3D1 MDT_POOL_SPM_LVER=3D30 MDT__SHA_CKSUM=3Dad43ad855d386b103a672a0801a932a9ee115ed7
Notably, see MDT_POOL_DOMAINS. Domains ec4ba43a-e334-4ce2-90d1-86e5a6da071d and a7af75fe-b96a-4ebe-8903-5743a8176311 no longer exist in the engine (we= re removed from admin UI).
Their presence in the metadata causes vdsmd to repeatedly try to acces= s those domains, resulting in constant error messages in the log that th= e domains don't exist.
Any advice on how to properly clean up the old domains from the metada= ta?
The easy way to do this is to use vdsClient tool:
vdsClient -s 0 forcedDetachStorageDomain <domain UUID> <pool UUID>
If you are not using secure connection (ssl=3Dtrue), remove the -s opti= on.
Nir
Thanks! This solved the issue! --2HL2sI0NmLbAoVBrOEQwsWUMqrns2ElTq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMNxboACgkQXOXFG4fgV76NRQCgkvEHmS43E+DUoirViiaRvuTM p3EAoNa37MtLCVgWJLAoPTNq3QRt9vjc =6PpQ -----END PGP SIGNATURE----- --2HL2sI0NmLbAoVBrOEQwsWUMqrns2ElTq--
participants (4)
-
Boyan Tabakov -
Elad Ben Aharon -
Gadi Ickowicz -
Nir Soffer