SEO

On Oct 10, 1:06 pm, Bela Lubkin <fi...@armory.com> wrote:
> "RLR" wrote:
>
> > The only drawback I've encountered running on VMware is that it's easy
> > to corrupt the virtual disk with an improper shutdown. VMware
> > provides tools that let the host OS do that safely for supported guest
> > OS's. Is there some workaround for that?
>
> You can certainly arrange for your virtual OSR5 to be shut down on
> demand. That is, if you _know_ you are shutting down the virtualization
> environment, you can take steps at the same time to shut down the VMs
> even if they are not going to be able to respond to internal signals
> from the virtualization environment.
>
> What's that mean?
>
> At the crudest level, it means: before you shutdown VMware, login to the
> OSR5 VM as root and shut it down manually.
>
> What refinements can you make on that?
>
> Well, you can shutdown the OSR5 box remotely by doing:
>
> ssh root@osr5vm shutdown -g0 -y # or whatever
>
>
> >Bela<

Shutting down the guest OS is not a sufficient condition to prevent
corruption of the virtual disk.

--RLR

Bob Meyers wrote:
> Thanks Brian and yes my CentOS 5 is 2.6.18. That may be the one I
> already tried. First problem I had was uname -r shows:
> 2.6.18-8.1.14.el5PAE, and it didn't have the same name in /usr/src/
> kernel.

Yeh that's controlled through the configure but don't you have to
download the sources for them to be in /usr/src/kernel? Also in the
above - isn't the kernel the 2.6.18-8.1.14 and then el5PAE is an addon
(sublevel controlled by the config) that denotes the particular build -
IE on my CentOS 4 the uname is 2.6.9-22.0.1ELabi. Seems the EL is
something Centos ads and I added the abi. This is so you can have
multiple versions of the same kernel and select the one you want at
boot.

I was thinking I could try a trial run (which would help me to) in a
vmware machine but I only have next week as I will be out of town for
the week after. Maybe I can find some time.

Bk

"RLR" wrote:

> > > The only drawback I've encountered running on VMware is that it's easy
> > > to corrupt the virtual disk with an improper shutdown. VMware
> > > provides tools that let the host OS do that safely for supported guest
> > > OS's. Is there some workaround for that?
> >
> > You can certainly arrange for your virtual OSR5 to be shut down on
> > demand. That is, if you _know_ you are shutting down the virtualization
> > environment, you can take steps at the same time to shut down the VMs
> > even if they are not going to be able to respond to internal signals
> > from the virtualization environment.
> >
> > What's that mean?
> >
> > At the crudest level, it means: before you shutdown VMware, login to the
> > OSR5 VM as root and shut it down manually.
> >
> > What refinements can you make on that?
> >
> > Well, you can shutdown the OSR5 box remotely by doing:
> >
> > ssh root@osr5vm shutdown -g0 -y # or whatever
>
> Shutting down the guest OS is not a sufficient condition to prevent
> corruption of the virtual disk.

I don't follow. If you shut down the guest OS and then the
virtualization environment, the result is the same as when shutting down
a non-virtualized OS on a physical machine.

Do you mean that you have to shut down the applications on the guest OS
first? Sure, that's true -- and if you've set things up correctly, that
should happen as part of the shutdown sequence. That is, you should
have shutdown scripts in /etc/rc0.d/... which shut down your apps in a
controlled manner, precisely so that initiating a shutdown from the OS
level leaves everything in a good state.

If you don't have that, then the proper shutdown sequence (from the
perspective of a remote machine) becomes:

ssh root@osr5vm command-to-shut-down-app-1
ssh root@osr5vm command-to-shut-down-app-2
sleep xxx # some amount of time known sufficient for those to complete
# unless there is some more active way to tell they're down
ssh root@osr5vm shutdown -g0 -y # or whatever
... shut down virtualization environment ...

All of this is identical to how you would shut down a physical machine,
only substituting "power off the hardware" in place of "shut down
virtualization environment".

>Bela<

Bill Campbell wrote:

> To get back on topic, given the relative efficiency of any of the
> SCO systems, they should fly under VMWare.

Hi, guys. I'm new on the group, and just got pulled into a contract to migrate OpenServer systems over to RHEL. (The handwriting is on the wall!)

Has anyone tried running Openserver under Xen, since Xen support is built into RHEL 5? I've worked with Linux for years, but not haven't done an Openserver install. How painful is it? And how painful is it to transfer a system dump to a bare metal re-installation?

Bill Campbell wrote:

> To get back on topic, given the relative efficiency of any of the
> SCO systems, they should fly under VMWare.

Hi, guys. I'm new on the group, and just got pulled into a contract to migrate OpenServer systems over to RHEL. (The handwriting is on the wall!)

Has anyone tried running Openserver under Xen, since Xen support is built into RHEL 5? I've worked with Linux for years, but not haven't done an Openserver install. How painful is it? And how painful is it to transfer a system dump to a bare metal re-installation?