|
You are correct aboutl the fact that I would like to have Web COnsole access from our remote users to be continuous without being affected by administering the maps. My only issue with them having the read-only map is that I have not seen device status function properlyo n the read-only maps. Where devices are changing status on the read-write map there is no corresponding change in status on the read only maps. Every night we run a script that updates new devices to add onto Netview. During this time I could shutdown the netviewd daemon and then restat it once I have finished with the addition of the new devices. But it still leaves me back to read-only maps do not propagate status correctly. -Chris Petrina
Chris I think what you want to do is avoid interrupting web console sessions... is that correct? Keep in mind that netviewd is basically ovw running as a daemon, with its display redirected to a virtual frame buffer. You can run netviewd with a read-only copy of the map by editing in the read only parameter to netviewd's lrf file, and then re-register it to incorporate the parameter into the ovsuf file via the ovaddobj command. Editing ovsuf directly is possible and effective, but be careful and remember to update the lrf file too. Our Knowledge Base article # 1121393 has additional information you can use on this (attached). Now that netviewd is using a read-only map, you can forget about netview -dconsole, and leave it running for your web console users to remain attached. You can bring up the read-write map for administration anytime without disrupting your web console users. However, should a web console user attach to your read-write map while you are adminstering, that web console will be disrupted when you close your map. Map updates, of course, are dynamic on the read-write map, but not on the read-only, so you may wish to establish a recycle schedule of your netviewd daemon depending on how dynamic your network is. Regards, Geo. George deSocio IBM Americas Support - Distributed Network Management Dept 46-E1ZA IBM B660 CC102 HWY 54 & 600 Park Offices Research Triangle Park, NC 27709 Expand your IBM Tivoli product knowledge by participating in Support Technical Exchange: http://www-3.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html
Chris, When Xvfb runs, it runs on a certain display(NetView usually uses :2 as the display). This is also normally present on the command line. So a ps -ef | grep vfb should let you know which display it is running on. To redirect NetView to that vfb, you can: 1) set your display and then run NetView export DISPLAY=netviewserver:2 2) I think you can run NetView with a -display option, ie: netview -display netviewserver:2 That should do it for you. Paul Christopher J Petrina wrote: > > Greetings all, > > is it possible to redirect the ovw (native GUI) to the Virtual Frame > Buffer. I know that netviewd requires the vfb to run. But is there a > way to point the Native GUI to use the vfb. We have no graphics card in > the Netview server, so was curiouis if the vfb would be a way to keep a > native GUI running. The problem is when netviewd runs, and a native > console is needed, we X windows into the server with the -dconsole to > gain the admin of it. This Kills all web console sessions. Once the > administration is complete, kill the native GUI in the X windows and the > web consoles again will have to be restarted when netviewd comes back > online. Would VFB help in this situation? > > Thanks > > Chris Petrina > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs SkyScan > service._______________________________________________________________ > > This electronic message contains information from MeadWestvaco > Corporation or subsidiary companies, which may be confidential, > privileged or otherwise protected from disclosure. The > information is intended to be used solely by the recipient(s) > named. If you are not an intended recipient, be aware that > any review, disclosure, copying, distribution or use of this > transmission or its contents is prohibited. If you have > received this transmission in error, please notify MeadWestvaco > immediately at postmaster@MeadWestvaco.com. > _______________________________________________________________________ ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service._______________________________________________________________ ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service._______________________________________________________________ This electronic message contains information from MeadWestvaco Corporation or subsidiary companies, which may be confidential, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify MeadWestvaco immediately at postmaster@MeadWestvaco.com. _______________________________________________________________________
|
