Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

comp.unix.aix Frequently Asked Questions (Part 3 of 5)
Section - 1.709: How do I remove a volume group with no disks?

( Part1 - Part2 - Part3 - Part4 - Part5 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Neighborhoods ]


Top Document: comp.unix.aix Frequently Asked Questions (Part 3 of 5)
Previous Document: 1.708: How do I fix Volume Group Locked?
Next Document: 1.710: What are the theoritical limits within the LVM?
See reader questions & answers on this topic! - Help others by sharing your knowledge

This is a very common question about AIX LVM and I thought
I might take some time to explain what is going on.  Within
a volume group is the Volume Group Descriptor Area (VGDA) is
is kinda a "suitcase" of lvm information.  This is what allows
you to pick up your drives and take them to another machine,
importvg them, and get filesystems automatically defined.

What happens is that when you importvg the volume group,
the RS/6000 goes out and reads the VGDA and finds out about
all the logical volumes and filesystems that may exist on the
volume group.  It then checks for clashes (name conflicts, etc..)
on its own machine and then, here is the important part, populates
its own database with information about the new volume group and
its associated logical volumes.  In cases of filesystems, it will
go into the /etc/filesystems file and add the new filesystem entries
that came along with the imported volume group.

Okay, the key point is that you've got this independent volume group
that has "docked" at the new RS/6000.  What keeps the two tethered
to each other is the varyonvg command.  When this is started on the
volume group, a software link is created where you can't separate the
volume group from the AIX operating system unless the volume group
is no longer seen as active by the system.  In very rare cases, a
situation can occur where the VGDA thinks that someone has it (the
volume group) activated, but the operating system doesn't think it has the
volume group opened up.  This is pretty rare.

The main question I see is "I've taken away the disks, but how do
I get rid of the volume group".  The question should really say,
"How do I get rid of the volume group INFORMATION" since that's
all you have on the system.  You've got possible entries in
the /etc/filesystems and definitely entries in the ODM.  Just 
do:
	exportvg <vgname>

It does a reverse importvg, except it doesn't go off and read
the VGDA.  It nukes anything relating to the volume group in
the /etc/filesystems and ODM.  The only time this won't work is
if the system detects that the volume group is varied on.  Then,
it would be like trying to change tires on a moving car, we won't
let you do it!

Some people are concerned that doing an exportvg will somehow damage
the volume group and/or its VGDA. As I said, all it does is affect the
information about the volume group on the RS/6000 box, not on the actual
disk platter itself.  Thus, the volume group you exported is safe to
take to another system.  The only time the VGDA gets overwritten is when
you create a new volume on top of it.

The second most often asked question is "How do I get rid of a disk
that is no longer really in the volume group?"

In this case, you DON'T want to do an exportvg.  What you want to do
is tell the system you want to cut out the memory of the old, bad disk
from the RS/6000 AND from the VGDA of the volume group.  You simply
do:

		reducevg -d -f <vgname> <hdname>

or if the hdname can't be found:

		reducevg -d -f <vgname> <PVID>

Be careful with this command.  Unlike the exportvg command, actions done
with this command WILL affect the VGDA information on the platter.

Hope this clarifies some questions about volume groups.

User Contributions:

But remnants' crop burning hits harvesting hard

This sunday, quite possibly 28, 2019 snapshot, Provided by the city service group, jointly for Jarniyah, contains been authenticated based on its contents and other AP reporting, Shows Syrians lifetime extinguish a fire in a field of crops, wearing Jaabar, Raqqa state, Syria. Thousands of acres of wheat and barley fields in both Syria and Iraq have been scorched by the fires within harvest season, that typically runs until mid June. "The life that we live here is already bitter, " stated Hussain Attiya, A farmer from Topzawa Kakayi in upper Iraq. "If the outcome continues like this, I would say that no one will continue to be here. I plant 500 to 600 acres on a yearly basis. still, I won't be able to do that because I can't stay here and guard the land day and night. "ISIS militants have a history of working with a "Scorched earth insurance coverage " In areas from that they can retreat or where they are defeated. Ahmed al Hashloum thoughts Inmaa, Arabic for benefits, A local civil group that supports farming. all it takes is a cigarette butt to set haystacks on fire, He brought up. Said the fires are threatening to disrupt normal food production cycles and potentially reduce food to protect months to come. The crop burning remains localized and can't be compared to pre war devastation, Beals considered that. "suffice to say, It is only the beginning of the summer and if the fires continue it could lead to a crisis, " Beals recounted,AlternativeHeadline,prepared crop burning blamed on ISIS remnants compounds misery in war torn Iraq and Syria"}

But good news is short lived in this part of the world, Where residents of the two countries struggle to face seemingly never ending violence and turmoil amid Syria's civil war and attacks by remnants of the Islamic State of Iraq and Syria (ISIS) social groups. of course, Even in locations where conflict has subsided, Fires currently raging in farmers' fields, depriving them of valuable crops.

The blazes have been blamed also consider on defeated ISIS militants seeking to avenge their losses, Or on Syrian regime forces battling to rout other armed groups. Thousands of acres of wheat and barley fields in both Syria and Iraq have been scorched by the fires within harvest season, what kind runs until mid June.

ISIS militants have a history of implementing a "Scorched earth guideline" In areas from which retreat or where they are defeated. this "A means of inflicting a collective punishment on those put aside, said Emma Beals, a completely independent Syria researcher.

ISIS militants claimed obligations for burning crops in their weekly newsletter, al Nabaa, Saying they targeted farms owned by senior officials in six Iraqi provinces and in Kurdish administered eastern Syria, sending the persistent threat from the group even after its territorial defeat.

ISIS said it burned the farms of "The apostates in Iraq together with the Levant" And required more.

"It seems that it'll be a hot summer that will burn the pockets of the apostates as well as their hearts as they burned the Muslims and their homes in the past years, this great article said.

countless acres of wheat fields around Kirkuk in northern Iraq were set on fire. Several wheat fields in the Daquq district in southern Kirkuk burned for three days straight yesterday.

In eastern Syria's Raqqa state, Farmers battled raging fires with items of cloth, bags and water trucks. Piles of hay burned and black smoke billowed above the job areas.

The Syrian Observatory for Human Rights said through 74,000 acres (30,000 hectares) linked farmland in Hassakeh, Raqqa and completely to Aleppo province to the west, Were scorched.

Activist Omar Abou Layla said local Kurdish led forces failed to react to the fires in the province of Deir el Zour, Where ISIS was uprooted from its last property in March, (...)

Comment about this article, ask questions, or add new information about this topic:




Top Document: comp.unix.aix Frequently Asked Questions (Part 3 of 5)
Previous Document: 1.708: How do I fix Volume Group Locked?
Next Document: 1.710: What are the theoritical limits within the LVM?

Part1 - Part2 - Part3 - Part4 - Part5 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
bofh@mail.teleweb.pt (Jose Pina Coelho)





Last Update March 27 2014 @ 02:11 PM