Work Related Sun / Solaris Stuff that I pick up from newsgroups and web sites

Friday, October 14, 2005

Veritas Volume Manager ! Changing Hostname

Veritas Volume Manager !

What are the effects of a *hostname change* on a serverwhich has all of it's drives including root/swapencapsulated by Veritas Volume Manager ??

I have had a worst experience with LSM ( Digital version ofVeritas Volume Manager ) very recently.

Gopala,

Veritas VM assigns ownership to objects based on hostname, if you changethe hostname, the system will no longer own the objects.

Ron

> Ron

If you forget to export the volume group, you can manually changethe volume group ownership to allow it to be reimported.

> > Any discussion on this will be highly appreciated.

It's not clear what the problem that you ran into was. Encapsulatedvolume groups aren't the cleanest part of Veritas volume manager.Worst case, don't start the volume manager, manually delete anythingyou can find of the encapsulated root volume group, restart the volumemanager and re-encapsulate the root volume group. Can't give youspecifics since I don't have a volume manager running currently.

If you had a stand alone boot disk w/ a copy of the volume manager onit, you could use it to change host ownership.

If it turns out that Veritas can't handle hostname changes, you couldhave always delete the root volume group before hand. Deleting volumemanager entities doesn't delete the actual data.

Offhand, based on what you haven't told us, that's all I can thinkof.

I have changed the host name of a machine running VM 2.6 (under Solaris 2.6)and nothing happens except that some processes are running with the old name,but all works fine.

Check out man vxdctl

The commannd is vxdctl init newname

vxdctl init new_name

To confirm the change (and you may want to save the file before thechange, just in case ...), look in /etc/vx/volboot(This is the name veritas is going to use during imports).

Good Luck.

Jeff Robinson / HDG

I> encapsulated by Veritas Volume Manager ??

None at all. VxVM doesn't care a whit what the hostname is.Now, if your hostid changes, you'll have licensing issues anddiskgroup attachment issues, but that's not what you asked.

K[Doug Hughes]

> None at all. VxVM doesn't care a whit what the hostname is.

Oh, if only that was true. VxVM didn't find the A1000 until wechanged the hostname into non-FQDN. Now, why it cares is a mystery.I wouldn't take any chances with that software...

> diskgroup attachment issues, but that's not what you asked.

Changing the hostname will not affect the volumes you've previouslyinstalled unless youissue a vxdctl init command which will change the output of vxdctllist (hostid in there) this will cause VxVM tothink the disks areowned by someone else.

<br>Now, if your hostid changes, you'll have licensing issues and<br>diskgroup attachment issues, but that's not what you asked.</blockquote>

<p><br>Changing the hostname will not affect the volumes you've previouslyinstalled unless you<br>issue a vxdctl init command which will change the output of vxdctllist (hostid in there) this will cause VxVM to think the disks are<br>owned by someone else.<> I wouldn't take any chances with that software...

That is a problem with rm6, the software that manages the A1000, notwith VxVM.

I believe that the latest rm6 fixes this, not 100% sure though.--

Actually what is happening is:As I said it is called LSM ( logical storage Manager,digital VxVM )I start the server in single user mode, then I can see thecontents of the /etc/vol/tempdb directory ( which containsall the disk groups listed ). Once I start the Veritasservices it locks out this directory. And every servicedepends on the contents of this directory. Thus allDiskgroups disappear from the picture, including vold ( onSun VXLD )daemon which is needed by all services and toolson veritas.My question is: Did it ever happen to anyone, wherein somedirectories/file systems, encapsulated by VxVM, are notaccessible in *run level 3* and are accessible in *runlevel 1* or when mounted as ReadOnly ??