[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] VG within VG

Hi James,

Firstly, thanks for the attention to my post.

Currently I use the following form:
1. I create a LUN in Storage and deliver it to the hypervisor.
2. I create a VG and an LV with this LUN.
3. I deliver the LV to the VM.
4. In VM already, I do a standard OS installation with VG and LVs.

What happens is that in the hypervisor layer, also appears the VG and LV created in the VM layer.

This situation has never been a problem, but it is an inconvenience because it always shows the message below:
WARNING: Duplicate VG name VGVM-BIN: lh4C8S-fwxt-yeD0-Y99K-B4PJ-mfuV-NXK8P2 (created here) takes precedence over o9A48e-h4zO-SZ3U-3wbw-AAjy-UmxT-N0zDjC

I do not usually mount the VG / LV of the VM layer on the hypervisor, but I had to do it a few times for backup, so I always mounted it as read-only and never had a problem.

Well, I'll take a look at this LVM filter issue.

Thanks again!

2017-01-12 11:50 GMT-02:00 James Dingwall <james-xen@xxxxxxxxxxxxxx>:
On Thu, Jan 12, 2017 at 10:40:47AM -0200, Jorge Visentini wrote:
> For example, I create a VG with the name of the VM, for example VGVM01 and
> then I create a LV (/ dev / mapper / VGVM01-LV) and delivered as a disk to
> the VM in virt-manager.
> What happens is that in this way, it becomes active in hyper both the VG
> that I create (VGVM01) and the VG that I create inside the VM and sometimes
> the duplicate VG message appears in the hypervisor.
> Is that correct, or do you do it differently?
I suppose there is the potential for LVM metadata to become corrupt if it can be written in both the hypervisor
and the guest.  I avoid this happening in my dom0 with an edit to /etc/lvm/lvm.conf to set:

global_filter = [ "a|/dev/md.*|", "a|/dev/sd.*|", "a|/dev/xvd.*|", "r|/.*/|" ]

This allows LVM to consider /dev/md* /dev/sd* and /dev/xvd* as possible pvs but ignore any other block devices.


Jorge Visentini
+55 55 8432-9868

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.