[libvirt] [PATCH]: vgscan before doing logical pool discovery
Assume that you have an iSCSI target available, and on that iSCSI target 1 LUN is exported. On that 1 LUN, you have an LVM volume group (say, myvg), with 2 logical volumes (say, lv1 and lv2). Now you execute the following sequence of commands: 1) virsh define iscsi_pool.xml 2) virsh start iscsi_pool 3) virsh find-storage-pool-sources-as logical With that sequence, you would expect step 3) to return XML similar to: <sources><source><name>myvg</name><device path='/dev/sdb'/></source></sources> However, what you instead get is: <sources/>. That's because if you just try to do storage pool discovery on a logical pool without ever touching the logical pool in any fashion, pvs (what we use to do discovery) doesn't return anything. If you touch the logical volume group at all (say, with vgscan), they then suddenly appear. To make sure we see all of the potential volume groups when doing pool discovery, make sure to run vgscan before we run pvs. With this patch in place, logical discovery just does the right thing. Signed-off-by: Chris Lalancette <clalance@redhat.com>
On Tue, Nov 04, 2008 at 06:32:37PM +0100, Chris Lalancette wrote:
Assume that you have an iSCSI target available, and on that iSCSI target 1 LUN is exported. On that 1 LUN, you have an LVM volume group (say, myvg), with 2 logical volumes (say, lv1 and lv2). Now you execute the following sequence of commands:
1) virsh define iscsi_pool.xml 2) virsh start iscsi_pool 3) virsh find-storage-pool-sources-as logical
With that sequence, you would expect step 3) to return XML similar to:
<sources><source><name>myvg</name><device path='/dev/sdb'/></source></sources>
However, what you instead get is: <sources/>. That's because if you just try to do storage pool discovery on a logical pool without ever touching the logical pool in any fashion, pvs (what we use to do discovery) doesn't return anything. If you touch the logical volume group at all (say, with vgscan), they then suddenly appear. To make sure we see all of the potential volume groups when doing pool discovery, make sure to run vgscan before we run pvs. With this patch in place, logical discovery just does the right thing.
ACK, this makes total sense. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
On Tue, Nov 04, 2008 at 06:32:37PM +0100, Chris Lalancette wrote:
Assume that you have an iSCSI target available, and on that iSCSI target 1 LUN is exported. On that 1 LUN, you have an LVM volume group (say, myvg), with 2 logical volumes (say, lv1 and lv2). Now you execute the following sequence of commands:
1) virsh define iscsi_pool.xml 2) virsh start iscsi_pool 3) virsh find-storage-pool-sources-as logical
With that sequence, you would expect step 3) to return XML similar to:
<sources><source><name>myvg</name><device path='/dev/sdb'/></source></sources>
However, what you instead get is: <sources/>. That's because if you just try to do storage pool discovery on a logical pool without ever touching the logical pool in any fashion, pvs (what we use to do discovery) doesn't return anything. If you touch the logical volume group at all (say, with vgscan), they then suddenly appear. To make sure we see all of the potential volume groups when doing pool discovery, make sure to run vgscan before we run pvs. With this patch in place, logical discovery just does the right thing.
ACK, this makes total sense.
Thanks, committed. -- Chris Lalancette
participants (2)
-
Chris Lalancette -
Daniel P. Berrange