Hi,
Paresh Devalekar wrote:
Hi,
I have one requirement, where I have to check, whether machine is physical or
VM (virtual machine)?
Anyone have idea, how to know it? Is there is any command or function which
can give me this info?
Is this with a specific virtualization product, eg
Thanks Danek,
unfortunately the script does not plan to fix anything on my system.
I also find out that I cannot run the packagemanager (UI does not start)
and really suspect that *.pyc files in SUNWPython and/or SUNWipkg-gui
are corrupted. Unfortunately pkgfix ignores the *.pyc files now.
On Tue, Aug 12, 2008 at 09:16:44AM +0200, Lubomir Petrik wrote:
I also find out that I cannot run the packagemanager (UI does not start)
and really suspect that *.pyc files in SUNWPython and/or SUNWipkg-gui are
corrupted. Unfortunately pkgfix ignores the *.pyc files now.
Yes. The .pyc
Failing a technical method, how about just naming your hosts as such (i.e. P
for physical, V for virtual)...
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
So it would seem no one has seen this error. Im gonna try the following from
another posting and see if that works.
I saw a posting similar to mine about using pkg add or something. Now to find
it again
Message was edited by:
unix1adm
This message posted from opensolaris.org
On 08/11/08 14:06, Sandy Stewart wrote:
My team would like to request that the Storage Community sponsor a project to
release the Sun KMS 2.0 API as an Open Source Module.
The intent of this project is to make available to any partner, the protocol
by which an arbitrary encryption agent can
Hi All,
We've setup a blogging infrastructure at http://blogs.nexenta.org. If
you have a Nexenta blog, or want one let us know, and we'll set you up
at blogs.nexenta.org/username.
We're also working towards NexentaCore Platform Alpha2, which will be
released in the near future. Contributions
I assume the zpool is on a second disk(s). If so, zpool export pool, do the
installation of _95 and zpool import pool. Your data will be safe even if you
don't export the pool, but, I'm paranoid. I used to do it that way before I
decided to try Live Upgrade.
--ron
This message posted from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Halstead wrote:
| I assume the zpool is on a second disk(s). If so, zpool export pool,
do the installation of _95 and zpool import pool. Your data will be safe
even if you don't export the pool, but, I'm paranoid. I used to do it
that way before I
I like your blog entry on using graphviz to view Nexenta package
dependencies graphically. Nice!
On Tue, 2008-08-12 at 22:49 +0530, Anil Gulecha wrote:
Hi All,
We've setup a blogging infrastructure at http://blogs.nexenta.org. If
you have a Nexenta blog, or want one let us know, and we'll
I read on a previous post somewhere that the menu-driven version of Live Update
- i.e. the lu command - doesn't wokr with ZFS due to a particular bug, but I
can't locate the original post. Doesanyone have a link to the bug in
bugs.opensolaris.org . Also, is this one that is going to be fixed?
* andrew ([EMAIL PROTECTED]) wrote:
I read on a previous post somewhere that the menu-driven version of
Live Update - i.e. the lu command - doesn't wokr with ZFS due to a
particular bug, but I can't locate the original post. Doesanyone have
a link to the bug in bugs.opensolaris.org . Also, is
There is a thread quite similar to this but it did not provide a clear answer
to the question which was worded a bit odd..
I have a Thumper and am trying to determine, for performance, which is the best
ZFS configuration of the two shown below. Any issues other than performance
that anyone may
andrew writes:
I read on a previous post somewhere that the menu-driven version of Live
Update - i.e. the lu command - doesn't wokr with ZFS due to a particular
bug, but I can't locate the original post.
The old FMLI-based menu-driven /usr/sbin/lu command has long since
been abandoned --
The setup in the first example protects you against failure of a complete
controller. The second configuration leaves you open significantly because you
only need to loose 2 disks before your data is toast.
Aside from that, stripes so large suffer in terms of performance.
Keep your stripes
Zpools are self contained, so as stated before its safe. In upgrades like this
I often will actually pull or disconnect the zpool disks just for paranoia sake.
As for the config of the existing machine, keeping a copy of /etc is never a
bad idea. I typically will rsync a copy of it out
Ben Rockwood wrote:
Zpools are self contained, so as stated before its safe. In upgrades like
this I often will actually pull or disconnect the zpool disks just for
paranoia sake.
As for the config of the existing machine, keeping a copy of /etc is never a
bad idea. I typically will
Ben Rockwood writes:
Upgrades get even easier if you put filesystems like /opt or /usr/local on
the zpool. Post-install just mount /opt and /usr/local from the zpool (zfs
set mountpoint=/usr/local pool/local zfs mount -a). I frequently upgrade
my Nevada boxes (read: reinstall) and
Ian Collins wrote:
Ben Rockwood writes:
Upgrades get even easier if you put filesystems like /opt or
/usr/local on the zpool. Post-install just mount /opt and /usr/local
from the zpool (zfs set mountpoint=/usr/local pool/local zfs mount
-a). I frequently upgrade my Nevada boxes (read:
Ian Collins wrote:
Ben Rockwood writes:
Upgrades get even easier if you put filesystems like /opt or
/usr/local on the zpool. Post-install just mount /opt and /usr/local
from the zpool (zfs set mountpoint=/usr/local pool/local zfs mount
-a). I frequently upgrade my Nevada boxes (read:
20 matches
Mail list logo
