Dec 122010
 

I recently had cause to restart a virtual machine on my ESXi host, but my usual method of firing up my Windows 7 machine and using the graphical manager was unavailable.

Fortunately the relevant instructions were obtainable from the http://vm-help.com/ site …

Firstly log into the ESXi host itself (which you previously have to enable), and run :-

vim-cmd vmsvc/getallvms

To obtain a list of the current virtual machines. Find the one you want to restart and find the ID for it in the first column. Use this in the following commands :-

vim-cmd vmsvc/power.reboot ${vmid}

This requires the vmware tools installed on the virtual machine, and for the tools to be running (i.e. the virtual machine needs to be reasonably healthy). If this is not the case, you will need to do the equivalent of hitting the reset button :-

vim-cmd vmsvc/power.reset ${vmid}

And that’s it! A lot quicker than the GUI way, unless you happen to have that always running.

Sep 222010
 

I have been looking into a problem with my Macbook Pro for quite a while now – despite setting the preferred sleep mode with sudo pmset -a hibernatemode 1, the laptop refuses to go into hibernate mode. It doesn’t even go into hibernate mode when the battery runs down sufficiently that it should do.

This leads to a couple of problems :-

  1. On occasions, the battery runs down enough to loose all power meaning my laptop switches off, and all running programs are terminated.
  2. Also the laptop sometimes comes out of sleep mode in my backpack getting very hot in the process.

According to a comment on a blog posting, there may be an issue with Firefox preventing hibernation from working – why that should be, I haven’t the faintest idea. Despite seeming a touch unlikely, I gave it a go – quitting Firefox and then putting the laptop to sleep.

And it hibernates!

However it turns out that stopping Firefox doesn’t prevent my main machine from hibernating. After a long hunt and several experiments, it turns out that OSX will simply not hibernate to a disk that isn’t in the slot where the hard disk is. Or in other words, you cannot hibernate when your boot disk in an SSD in the ExpressCard slot.

Which strikes me as a bit … weird. I guess the fix for this would be a proper SSD in the hard disk slot and to move the hard disk elsewhere.

After having invested in an SSD and spent far too long forcing my tired old eyes to operate in my MBP, I can confirm that hibernation does work with any kind of disk in the right slot for the hard disk.

Feb 272010
 

One of the great things about OpenSolaris is that the archaic packaging tools have been replaced with something that looks like it may be a little better; one of the disadvantages is that trying to install packages from something like OpenCSW is a little awkward when the first command fails.

Given that I’ve just to hunt around for the details a second time, it is worth working up the basics into something that can be added here. Firstly we need to install the commands necessary to support the old packages :-

pkg install SUNWpkgcmds
pkg install SUNWwget

Now that has been done, it should be possible to install the OpenCSW package command using pkgadd :-

pkgadd -d http://www.opencsw.org/pkg_get.pkg
Nov 082008
 

Well I decided it was time to upgrade my main workstation to Ubuntu 8.10 from 8.04. This was a somewhat nervous upgrade because the SATA disks are connected to a controller that gives me trouble when booting … the last few times I rebooted the machine I have had to re-assemble one of the mirrors at the “miniroot” (the shell you get from the initrd environment).

Given the trouble I wanted the option to revert back to the current install if everything went wrong … something I have described in the past.

Environment

I have four SATA disks in my main workstation that are mirrored and encapsulated into a single volume group with numerous logical volumes. So /dev/md0 is constructed of a mirror of /dev/sda2 and /dev/sdb2 and /dev/md1 is constructed of a mirror of /dev/sdc1 and /dev/sdd1. /dev/sda1 is used as /boot and /dev/sdb1 is “spare”.

The volume group datavg has two “physical disks” in it – /dev/md0 and /dev/md1. In that volume group are (amongst others) two logical volumes of interest – 804root and 804var.

Preparation

First I ensured that /dev/sdb1 contained an up to date copy of /boot :-

mkfs -t ext2 /dev/sdb1
mount /dev/sdb1 /mnt
star -copy /boot /mnt
umount /mnt

The next step was to create two new logical volumes to be used (eventually) for the new release of Ubuntu :-

lvcreate --size 12G -name 810root /dev/datavg
lvcreate --size 3G --name 810var /dev/datavg
mkfs -t xfs /dev/datavg/810root
mkfs -t xfs /dev/datavg/810var

The next step was to copy the filesystems across – at this point no further non-upgrade activity took place :-

mount /dev/datavg/810var /mnt
star -copy -xdev /var /mnt
mount /dev/datavg/810root /mnt
star -copy -xdev / /mnt
(edited /mnt/etc/fstab to change references to 804 to 810)
umount /mnt

At this point the remaining task (or so I thought) was to change the references in /boot/grub/menu.lst so that Grub would boot the kernel with 810root as the root filesystem.

I then rebooted to check the functionality and discovered that for some reason /var/run/network had not been created on the new /var but that seemed to be the only issue. I re-created this directory and rebooted to be sure (and Linux without a loopback device behaves very strangely!).

I then in theory had an environment I could revert to with a bit of fiddling with grub so was happy to attempt the upgrade.

The Upgrade Itself

I then started the upgrade (sudo update-manager -d) only to be told I did not have enough disk space with the suggestion that I run sudo apt-get clean to free up enough space. I tried this and the update started on the next time through. Why doesn’t the upgrade process automatically run apt-get clean ? In fact why doesn’t the upgrade process realise that it is on a system with LVM available (with plenty of free space) and create a new LVM especially for the upgrade files ?

Anyway the second attempt to run update-manager did start downloading files so I settled down for a well earned beer.

After the files had downloaded the actual upgrade process began. At some point the process stopped whilst a certain upgtade (libpam) asked whether it should restart certain services (including gdm which is the graphical login). Unfortunately it did not explain clearly what it was doing, why, or even if restarting gdm would terminate the current X session. Perhaps it is something that would only “worry” someone with a dangerous amount of knowledge, but perhaps the prompt could be improved slightly.

As a later example of how it should be done, the dialog warning about changing the ssl certificate was ideal … basically saying “if this doesn’t mean much to you, don’t worry about it”.

The use of dialogs during the upgrade does raise a couple of issues though :-

  1. Apparently not “stopping the clock” whilst waiting for the user to respond to dialogs caused the estimate of how long the upgrade would take place to increase dramatically. Just after dealing with that libpam prompt I was slightly alarmed by the estimate of 6 further hours to complete (as it was already 21:30) only to be reassured by the rapid drop to 2 hours.
  2. From a users perspective it would be preferable to ask all questions at the beginning or at the end of a long process. Keeping an eye on the upgrade whilst it was churning through the bulk of the upgrade (which took place without user intervention) was somewhat tedious.

The unfortunate thing was that at this point, the upgrade process ran out of space. It also left my machine in an unbootable state … from what little investigation I made it would appear that the initrd file was not created. Perhaps because of the lack of space, but others have also encountered this problem.

Obviously the Ubuntu upgrade process should be a little more careful about estimating the amount of space available. It would also be nice if it would notice that it was installed on an LVMed system with free space available … it could create a new LVM of an appropriate size and use that.

Recovery

Fortunately my preparation left me with a root filesystem that I could revert to by selecting one of the older kernels in the grub menu, editing the command used to boot, and by replacing the root filesystem with “804root”. This resulted in a system almost identical to that before the upgrade process.

I re-tried the “Preparation” stage, ensuring that /var was a little bigger and restarted the upgrade process …

Upgrading (The Second Attempt)

The second upgrade went through pretty much the same process as the first … except that it did not run out of disk space. This let it complete apparently normally with a warning about removing several hundred packages (!).

Finally it suggested rebooting to finish the upgrade.

The First Boot

The first boot was a triffle problematic … firstly I still had to manually assemble /dev/md0 and the process that built /boot/grub/menu.lst hadn’t noticed that an invalid root filesystem was specified. Whilst the later was my fault, it would be nice if it had realised that it was invalid and had warned me. The former is a long standing problem and is not the result of the upgrade.

Apart from that, the standard user interface looked ok, but it had messed around with the Enlightenment window manager. I had to re-install the package, my settings and menus had disappeared. Whilst I am an “unusual” user in not using the standard user interface, this was not something I was happy with!