From mboxrd@z Thu Jan 1 00:00:00 1970 References: <5AB52B8D020000F9000B14B9@prv-mh.provo.novell.com> <229d22d1217a7fa96874df0fb6d53e0c@xenhideout.nl> <5AB8FDE7020000F9000B19DD@prv-mh.provo.novell.com> <5ABA4D6D020000F9000B1E44@prv-mh.provo.novell.com> From: Zdenek Kabelac Message-ID: <9d5323b7-73e7-0112-8e94-58613abe783a@redhat.com> Date: Tue, 27 Mar 2018 10:32:45 +0200 MIME-Version: 1.0 In-Reply-To: <5ABA4D6D020000F9000B1E44@prv-mh.provo.novell.com> Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] Can't work normally after attaching disk volumes originally in a VG on another machine Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: LVM general discussion and development , Gang He Dne 27.3.2018 v 07:55 Gang He napsal(a): > Hi Fran, > > >>>> >> On 26 March 2018 at 08:04, Gang He wrote: >>> It looks like each PV includes a copy meta data for VG, but if some PV has >> changed (e.g. removed, or moved to another VG), >>> the remained PV should have a method to check the integrity when each >> startup (activated?), to avoid such inconsistent problem automatically. >> >> Your workflow is strange. What are you trying to accomplish here? > I just reproduced a problem from the customer, since they did virtual disk migration from one virtual machine to another one. > According to your comments, this does not look like a LVM code problem, > the problem can be considered as LVM administer misoperation? > > Thanks > Gang Ahh, so welcome Eric's replacement :) Yes - this use scenario was improper usage of lvm2 - and lvm2 has cached the user before he could ruing his data any further... Regards Zdenek