Thinking of upgrading your vCenter Server Appliance from a 5.0 image to the 5.1 image using the official VMware upgrade process covered in the documentation? Don’t do it. It fails somehow. Every time.
Unexpected error during the upgrade process.
To attempt to upgrade again, restore the old vCenter Server Appliance and external database from backup/snapshot, deploy the new vCenter Server Appliance again and start the upgrade process from the beginning.
Yeah.. you read the right. Now both your old and new appliance images are b0rked, and you’ll need to restore from the vCenter 5.0 backup that you definitely made before attempting the upgrade. In private emails, VMware has acknowledged the issues and has advised to stick with 5.0 and hold off on upgrading the vCenter Server appliance until the next major release since the upgrade/migration tools are such horrible crap. Time to sit back and wait it out!
Update: The built-in update tool in 5.0 that allows you to apply point release upgrades is also fairly broken. (See the red “Failed to install..” message in the background?)
Apple now allow you to virtualize OS X Server instances. While your virtualization options are limited, it’s very easy to set up on your existing OS X Server.
This is an virtualized OS X Leopard Server guest running in Parallels Server on a host OS X Leopard Server. You can see that the guest system is treated similarly to other Windows and Linux VMs in the Parallels Management Console.
Note that a distinct serial number/license seems to be required. The serial number for the host machine will not validate (I thought Apple was going to allow one VM instance???), so to use the sweet service configuration tools available in Server Admin, it appears you’ll need a separate license for now.
After a few grumpy emails between myself and our Account Manager, I’m happy to report that we have purchased the GA release and it’s working well. If you are using Parallels Server for internal development purposes and not for hosting, they will extend a more reasonable price per machine: $200 + $50/year maintenance. I think that’s a very reasonable price point for our usage, and am happy to pay it.
This likely has more to do with meeting end-of-Q2 sales quotas than attracting my dinky business, but regardless, a win is a win! Thanks!
Fresh from my inbox..
Parallels Server for Mac will be available soon. As a thank you to all participating Parallels Server for Mac Beta users, Parallels is offering an exclusive discount on a single Parallels Server for Mac license. Purchase this new software for only $700* – a 30% savings.
Hmm… well, the product has been working fairly well for us at OpenRain, but I’m not sure $700 per major version is going to be worth it as opposed to buying another cheap Dell machine and running VMWare Server on Linux for free, which we already do in some of our hosted environments. Here’s the kicker in tiny font at the bottom of the email explaining the asterisk after “$700”..
* The limited-time discount offer is limited to a single server from May 30 – June 30, 2008. Annual maintenance is required at the time of purchase, starting at an additional $249.75 per year. For academic pricing and volume licensing, register now or contact Parallels Sales at +1 (425) 282-6400.
So that’s $950 for the first year of our first system alone. Hmmmm…
OpenRain used a slew of crappy Trac sites for issue tracking until we switched to Redmine several days ago. The decision came because..
- Redmine can authenticate off LDAP with trivial configuration.
- Redmine has multi-project support out-of-the-box.
- Redmine has some nifty Gantt chart and calendaring schwag and is generally better.
- Parallels Server (for OS X) is finally available.
- JumpBox has a beta Redmine VM image available.
If you’ve got an existing LDAP infrastructure, the whole shebang shouldn’t take more than an hour or two to set up.
- Install Parallels Server on your OS X Leopard server.
- Download the Redmine JumpBox. Generate a new MAC address and boot it. Do the one-page configuration thingy in your browser.
- Log into Redmine and create a new “Authentication Mode” set to LDAP. If you’re using the default OpenLDAP schema that ships with Leopard server, enter the attributes like so..
- All your users should now be able to log into your Redmine JumpBox using their LDAP credentials! You’ll have to set up your projects, ACLs etc. within Redmine, but that’s some pretty hot shizzle to get running in such a small timeframe.
Mad props to Redmine, Parallels, JumpBox and Apple for further simplifying my business.
This is an abbreviated and simplified version of a more official document. Run these either as root or with the “sudo” command..
- apt-get install ubuntu-xen-desktop-amd64 to install a new Xen kernel and various other tools. Apparently we’re supposed to use the “server” version instead, but it didn’t show up in the repository. Oh well.
- apt-get install debootstrap to install the “debootstrap” system bootstraping tool for you.
- reboot into the new kernel.
- xm list to make sure Domain-0 shows up. Domain-0 represents the host system.
- Edit /etc/xen/xend-config.sxp and uncomment “(network-script network-bridge)”. Also comment out “(network-script network-dummy)”.
- xend restart to restart the xen daemon.
- mkdir -p /xen/slave1 to create a mountpoint for the slave system disk.
- dd if=/dev/zero of=/xen/slave1.ext3 bs=1M count=512 to create a 512MB “disk” as a normal file.
- mkfs.ext3 /xen/slave1.ext3 to create a file system in said empty file.
- mount -o loop -t ext3 /xen/slave1.ext3 /xen/slave1 to manually mount the new filesystem to its mount point.
- debootstrap –arch amd64 edgy /xen/slave1 to install a bare bones edgy system onto the new file system.
- cp -a /lib/modules/2.6.19-4-generic-amd64/ /xen/slave1/lib/modules/ to install the hosts kernel modules into the new system.
- Edit /xen/slave1/etc/network/interfaces. It should look similar to..auto lo
iface lo inet loopbackauto eth0
iface eth0 inet static
where “gateway” is the host machines IP address, and “address” is a unique IP address for the slave machine.
- Update /xen/slave1/etc/hostname with whatever you want its host name to be.
- Update /xen/slave1/etc/hosts with all your IP addresses.
- Update /xen/slave1/etc/fstab to mount stuff on boot, like so..proc /proc proc defaults 0 0
/dev/hda1 / ext3 defaults,errors=remount-ro 0 1
- umount /xen/slave1 to unmount the file system.
- Create /etc/xen/edgy-guest.cfg to configure the host to start the guest, like so..
kernel = “/boot/vmlinuz-2.6.19-4-generic-amd64”
ramdisk = “/boot/initrd.img-2.6.19-4-generic-amd64”
memory = 512
name = “edgy-slave1”
vcpus = 1
vif = [ ‘bridge=xenbr0’ ]
disk = [ ‘file:/xen/slave1.ext3,ioemu:hda1,w’ ]
root = “/dev/hda1 ro”
- xm create slave1-edgy.cfg to create and start the new domain.
- xm console slave1-edgy to establish a console to the new domain. (Hit CTRL+] to exit.)
You should now be able to log in via the xm console as root, and ping the guest on 192.168.1.111 (or whatever its IP address is). w00t!
I tried Parallels Desktop‘s Coherence mode today, and was so blown away I had to blog about it immediately.
The above image has not been doctored. It’s my normal OS X desktop with Windows XP running in coherence mode. When activated, the window around the XP virtualization session vanishes, the XP taskbar integrates into your OS X desktop, and XP application windows are free to float around. With Parallels Tools installed each XP application has a dock item which can be Command-Tabbed to. If you look closely you can see I’m running IE 6 next to Safari, both natively, without the visual distraction of the virtualization window. This is a huge usability landmark. Thank you Parallels!
Try it yourself by selecting the View -> Coherence menu option when running Parallels Desktop.
(Question: Does VMWare currently have a feature like this?)