[libvirt] [PATCH 3/3]: Implement logical stopPool and deletePool more fully

Daniel P. Berrange berrange at redhat.com
Tue Sep 23 08:59:35 UTC 2008


On Tue, Sep 23, 2008 at 09:30:46AM +0200, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> >> 3)  In deletePool, remove the -f from the vgremove command.  Besides the fact
> >> that we probably don't usually want to force things, the -f option doesn't exist
> >> prior to F-9, so this would fail on F-8, RHEL-5, etc.
> > 
> > Hmm, are you sure it won't prompt for a y/n confirmation ? IIRC, that was 
> > the reason I put in the -f. Perhaps simply ensuring stdin is /dev/null
> > takes care of that problem.
> 
> This was already committed, but just to follow-up:
> 
> First, I was wrong about RHEL-5.  Apparently we've rebased the LVM tools in
> RHEL-5, so it does have the -f flag for vgremove.  That being said, it's not
> actually necessary, based on my testing.  Here's what I did:
> 
> 1)  pvcreate /dev/sdb
> 2)  vgcreate MyVG2 /dev/sdb
> 3)  lvcreate -L1G 0n guest1 /dev/MyVG2
> 
> At this point, I have a valid volume at /dev/MyVG2/guest1
> 
> 4)  lvremove -f /dev/MyVG2/guest1 (this corresponds to the code in
> virStorageBackendLogicalDeleteVol)
> 5)  vgremove /dev/MyVG2 (this corresponds to the new code in
> virStorageBackendLogicalDeletePool)
> 6)  pvremove /dev/sdb
> 
> All commands completed without prompts, and remove the logical volumes.  In step
> 4), if I do a vgremove, *then* I get a prompt saying:
> 
> "Do you really want to remove volume group "MyVG2" containing 1 logical volumes?
> [y/n]: n"
> 
> But that's only because you are trying to de-activate a volume group that has
> active logical volumes.

Ah well that's the edge case then. There is no requirement in the libvirt
virStoragePoolDelete method that says all volumes must be removed before
calling it. So its certainly possible we'll ht this scenario. We either 
have to explicitly remove all volumes ourselves in the Delete method, or
we can trap & raise an error indicating that the app must remove them all.
I tend towards the latter.

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 :|




More information about the libvir-list mailing list