So when a VM runs on your hypervisor, it opens up a listening port for VNC/Spice connection.  What is probably happening is when RHEV-M brokers a connection to the correct hypervisor:port, it tells VNC or Spice client the  IP address of the hypervisor, rather than a hostname.  If you’re using a browser on a machine without a rhevm net connection, it just hangs.

This issue has been brought up in Red Hat’s Groups forum (login required).

The only thing to do is to create a dual-homed, Windows terminal server, attaching one address to the rhevm net.  Users can use this system for RDP connections and an Internet Explorer with access to your rhevm net.  Setting this up was easy for us because our RHEV-M server is a VM running on a master host with both corporate and rhevm network bridges.  Note that there are severe problems with spastic mouse pointer movement in Spice consoles on Win2k8 (and probably any VM with a graphical desktop) VMs.  VNC seems to work fine.

Plans have been made to move the hypervisor rhevm interfaces to corporate ip space.

The default range appears to be only 256 addresses, with only the last byte being 00-FF.  Not sure if RHEV 3 has a gui configurator, but here’s the fix on the command line (addresses fabricated):

[root@rhevbox ~]# rhevm-config -s MacPoolRanges='00:1C:DD:1E:00:00-00:1C:DD:1E:FF:FF'
[root@rhevbox ~]# service jbossas restart

Which provides 65,536 addresses and should be sufficient.

Now there’s an incoherent result in Google’s database:

The Wikipedia page was hosed as well:

I went ahead and removed the link for now.  Looks like a GoDaddy domain that expires in Sept. 2012, so that’s not the issue.

Naughty boy, you no pay hosting bill! -Peggy

First I installed virt-v2v. Virt-v2v will happily install with out 2 packages needed for converting Windows hosts: the ‘libguestfs-winsupport’ and ‘virtio-win’ packages. The former is a new package for RHEL6, I don’t believe the latter is.

What’s delightful is that this is completely undocumented in the RHEV documentation. The virt-v2v failure messages give no useful info. It IS documented the V2V guide for RHEL6 here, as well as in a couple of bugzilla reports, such as Bugzilla 600151.

If you happen to miss these, you may waste a considerable amount of time, as I (and my annoyed coworker) did today. The end result was that our maint window passed and we had to bring the system back up. Something to be aware of. Apparently the entire set of docs, as well as the error messaging code in virt-v2v will be updated in 6.1.

This press release was issued last month and I missed it completely.

SANTA BARBARA, Calif. – December 15, 2010 – Eucalyptus Systems, creators of the Eucalyptus private cloud platform, today announced a partnership with Red Hat, Inc., the world’s leading provider of open source solutions, to offer the freedom of cross-cloud compatibility and expanded customer choice in the cloud. The two companies are collaborating to provide Eucalyptus support for Red Hat Enterprise Virtualization and Eucalyptus compatibility with the Apache Deltacloud application programming interface (API).

Read the full press release on Eucalyptus Systems’ web site. Or read The Register’s article about it.

My guess: A version of Eucalyptus Enterprise Edition will be offered as an cloud user portal add-on for RHEV 3.0 early next year. But what about the proprietary bits in EEE?

GRUB screen

Boot proceeds and hangs for about one minute, then you see the following, then the VM hard resets:

Boot console

According to the guest support status page on the KVM site, versions 1 and 2 work under KVM. I’ll try a bare metal install at home tonight an see how that goes.