Archive for August, 2010
Although this is not recommended, for emergency cases you can set the vyatta root password using vyatta user account as below :
- #set system login user root authentication plaintext-password mynewpassword
Might useful to some of you :
- $yum install make (407KB)
- $yum install gcc (34M) -> path -> /usr/bin/gcc
- $yum install kernel-devel (20M) –> path –> /usr/src/kernels/184.108.40.206-85.fc13.x86_64/include/
- $mkdir /tmp/vmware
- $cd /tmp/vmware
- $tar -zxvf /media/VMware\ Tools/VMwareTools-8.3.2-257589.tar.gz
- $cd vmware-tools-distrib/
- Logout & login back
- Restart x server
Notes : New initrd will be created during this Vmware Tools installation. I Recommend you to take a snapshot for roll-back purpose before you are going to install it.
Give myself a minute to try the installation of Fedora 13 on ESXi 4.1. Wondering if I can find anything special on this release compare to the other distro. Once VM created, I just set the memory to 1024MB and 1 vCPU for this 64bit Fedora and ready to give ago.
At the beginning of the installation I discovered that, there is an option (storage) for you to install Fedora image onto SAN & DAS. Well, this sound good to someone who want to try to boot up their OS image from other than normal storage (vmdk). Default partition layout is nothing much different from Redhat default installation. One default LVM volume is enough and ext4 remain as Fedora default file system type. The rest of configurations are very similar to Redhat. What surprised me was, the installation only took less than a minute to complete. Read moreNo comments
Well, this is the most troublesome P2V Redhat 64bit machine I ever had this year. Although it was recommended to run $mkinitrd first on the source machine before P2V it. Unfortunately for some reason, we decided to only run $mkinitrd later once the conversion completed.
After almost two hours waiting, the Redhat conversion suddenly failed at 97%. If you experience this before, failed at 95% most likely your VM conversion stuck at the Grub configuration. While at 97% this is highly because of initrd configuration failed for the VM and if you proceed to power on this VM, you can expect the boot process will going to fail with error message “kernel Panic not sync”. So, why this problem happened?. Well this probably caused by new initrd image not properly configured or the converter not even configure at all new initrd with proper scsi driver (mptscsih) for the new VM and this surely causing root device can’t be mounted.
No matter what causing this, I’ve decided to make new initrd image for this VM but before that, I did minor troubleshooting steps as below :
Sigh, due to general support for ESX 3.5 U3 and vCenter 2.5 U3 already finished, me and my colleague (Mr.Lai) have to work tonight. We are going to upgrade all four ESX 3.5 U3 to U5 and vCenter 2.5 U3 to U6 at the same time. Hopefully both HP blade 460c and FalconStor NSS storage doesn’t cause me anything after we upgrade it. BTW, I’m thinking, why not we go for vSphere 4.0 or 4.1 right?
Nevertheless, I’m going to take my sahur at Kg.Baru “Nasi Lemak Antarabangsa” later. Read more
Another short “how to” VMware Update Manager(VUM) Installation 4.1 from me :
My Setup :
- Windows Server 2008 64bit (VM)
- vCenter 4.1
- SQL Server 2005 Express
- System DSN32 bit
- C:\drive = 8gb
- VUM Installation Media (.iso)
Notes : You will need system DSN 32bit for VUM installation using other than SQL server 2005 express which come together with VIM-4.1 installer. Please check this url on how to create 32bit system DSN.No comments
Silly, after successfull scheduled power maintenance today in our office, I’ve been asked by my Boss to power on remotely virtual machines (VMs) in vSphere Hypervisor 4.1 via TSM mode (SSH). On legacy ESX, I always do this using vmware-cmd command (vmware-cmd /vmfs../../.vmx start trysoft) and this shouldn’t be a problem to me. Once my Boss said he already powered on the hypervisor, I wait a few minutes till SSH service is fire up and running. Then, with full confident I run command “$vmware-cmd -l” to view the list of registered VMs available on this host and you know what? Surprisingly there is no vmware-cmd command was found. Okay my next try is to use “$vimsh” command instead but as expected, the command also cannot be found in this ESXi 4.1 host. Huh! after 10 minutes, my Boss called me and said he still cannot login to Exchange 2010 (one of the VM). Sigh, I know I can do this from vSphere RCLI but I have to download it first before I can use it from any workstation. Okay, my last resource is VMware KB . Luckily I found the actual command which can power on the VMs via TSM :
- $vim-cmd vmsvc/getallvms
- $vim-cmd vmsvc/power.on VMID
- $vim-cmd vmsvc/power.on 32
Hehehe I never thought vimsh & vmware-cmd have been taken out from ESXi.No comments