RHEV wishlist / feature requests

Latest response

I've been playing with 3.0 for a little while now, and while it's a marked improvement over 2.2, there's some things that I'd like to see added, and I'm sure I'm not alone.

 

 

  • Balloon support.  This seems like a bit of an obvious way to cut down on KSM load and give a bit more flexibility.
  • Per-user resource quotas for storage, vcpus, memory (I've heard that this is coming in 3.1, but wanted to mention it anyway, as it's pretty important to us).
  • Integrated IPA user management in the admin console.  The "Add user" command should actually be able to add a user, not just enable an existing IPA user.
  • Admin console log viewer.  Messages telling the user to "See logfile" are not helpful - the logfile should be viewable within the admin console.
  • Better support for attaching an iSCSI LUN directly to a VM.
  • DHCP/DNS integration, so that guests can be assigned an IP.
  • SAN integration to leverage the (usually much superior) snapshotting, thin provisioning, etc features of a SAN rather than doing it in software.
  • Increase the amount of actions hooks can be applied to - in particular hooks for VM create/delete would be nice.

 

I'm sure there's other things too that would be nice to have, but this is a start.

Responses

I agree with these points and would also like to add:

  • Ability to provision RHEV hypervisors using kickstart. Having to pass installation options as kernel parameters via PXE is not great. There is also a character limit which is easily hit when including IP/mask/gateway, partition layout and password hashes for admin and root.

move one host to anonther cluster in the same datacenter  ,or to another datacenter . this could be done  easily in m GUI

???

 

You can do this (or at least, you can in RHEV2, and if you can't in RHEV3b it's only because of bugs!).  Put the host into maintenance mode and then edit it.  You can then select a different Data Center and/or Cluster from the drop-down menus.  RHEV-M will then trigger a reconfiguration action on the host, after which you will be able to activate it - assuming that the host can access all of the new datacenter's storage, and is compliant with the datacenter's networking requirements (Data Centers -> Logical Networks), and the cluster's CPU family and compatibility version (Clusters -> Edit -> General).

Using CTRL + ALT to release the mouse cursor and keyboard from a VM console would be better as its the standard way (VMWare, Xen and Virtual Machine Manager).

You can do this yourself.  For the RHEV 3 beta, run this on your RHEV-M server:

 

rhevm-config -s SpiceReleaseCursorKeys=ctrl+alt --cver-general

 

The equivalent in RHEV-M 2.x can be found in

 

Start -> Programs -> Red Hat -> Configuration Tool -> Miscellaneous -> SPICE Release Cursor Keys

 

You may also want to change the fullscreen sequence (SpiceToggleFullScreenKeys) to ctrl+alt+enter.

 

You'll need to restart RHEV-M after making the changes.

I've seen these and discussed them with engineering, but I see I missed to update on this thread.

Most of them are already in planning or implementation phases. Just few question as I'm going to file RFE for some of those that are not:

  • DHCP/DNS integration, so that guests can be assigned an IP.
    • Do you mean RHEV Manager to provide DHCP and DNS?
      Now that RHEV manager is on RHEL hosts there should be no problem adding those yourself as services on the same host. So what do you suggest? To allow doing  this from the management GUI? 
  • Increase the amount of actions hooks can be applied to - in particular hooks for VM create/delete would be nice.
    • I'll file an RFE
  • Integrated IPA user management in the admin console.  The "Add user" command should actually be able to add a user, not just enable an existing IPA user.
    • I'm not sure RHEV will take that path actually the tendency is to leave this to the domain administrators and be domain agnostic.
      Actually  the local IPA configured in the rhev-setup script in beta is now deprecated and API is now supported in the same manner as active directory is. For this there is now the rhev-add-domains utility.\

Keep the feedback coming, this is very useful

This is only one many additional feature requests I have for RHEV2 and/or RHEV3, but has so many subfeatures that I thought it deserved a post of its own:

 

I would like the ability to edit virtual disks once created, specifically:

 

  • Change type from IDE to Virtio (albeit with Big Scary Warning about potential to render unbootable), as this is essential for converting FV VMs (particularly Windows ones) to PV.  This is purely a metadata change, which I at present I can only achieve by hacking the SQL database.
  • Enlarge a disk.  This is a trivially simple operation for LVM (SAN/iSCSI) disks, and pretty simple (using a careful dd) for raw NFS disks also.  Of course, this is only half the job because the guest O/S still has to repartition the disk and/or enlarge filesystems/LVM to make use of the extra space (so another Big Scary Warning here, I guess), but there are good third-party tools for doing this (Parted Magic etc).  End-users frequently ask for disk space increases, and adding additional disks is not always a good solution (particularly for Windows VMs ("C: drive or bust" syndrome)).
  • Convert thin provision disks to preallocated (e.g. when they consume 120% of actual size, slow to a crawl, and fragment all hell out of your storage!).  This is also needed to convert COW format VMs to Raw so that you can move them from NFS to SAN/iSCSI (LVM) via an export process.  The conversion involves a staightforward (if time consuming) "qemu-img convert" operation that could be done as an automated background task.
  • Rebase images that are dependent on templates (thin provisioned) such that they are "divorced" from the template (i.e. template dependency changes to "Blank").  This is the only way to get rid of old templates!  At present I have to do this by exporting the VM, manually rebasing using qemu-img and then reimporting; could be easily automated as a background task).

I've since learned that RHEV's "collapse snapshots" option when exporting VMs (and in RHEV3, also when importing) actually does most of what I was aiming for in bullet points three and four above, i.e. flatten the disk history hierarchy into a single image and convert to raw-preallocated format.  Hence you can export collapsed and then re-import to either (a) move from NFS to LVM (what RHEV3 calls V1 format to V2 format), or (b) divorce a disk image from the template on which it was based.

 

Since these operations would be rarely required, I can live with the inconvenience of that workaround, so I hereby retract my feature requests in the last two bullet points in the above posting.

 

However, someone needs to come up with a much more explanatory label than "collapse snapshots", because it's not at all obvious from this that the operation has anything to do with thin provisioning or templates!  How about something like "collapse snapshots and templates" with a mouse-hover tooltip that explains in more detail?

Hi Paul,

 

can you explain what exactly has to be changed in the DB to Change HD Controller Type from IDE to VirtIO

 

Thanks!

Red Hat provides virt-v2v for virtual-to-virtual conversions (although last time I checked, this was pretty useless for anything other than Xen <--> KVM, Xen/KVM --> RHEV and VMware ESX --> KVM/RHEV conversions of RHEL VMs), but absolutely nothing for physical-to-virtual conversions.  This makes it difficult for enterprises wanting to achieve all of those consolidation gains that they've read that virtualisation will give them, which might be a bit of a disincentive for forking out money to Red Hat for RHEV subscriptions!

 

My own clumsy O/S-agnostic workaround relies upon a competitor's product, namely VMware vCenter Converter Standalone.  Using RHEV Manager, you can manually create the empty shell of a target virtual machine with preallocated (but empty) disks - initially using full virt NICs and disk controllers rather than paravirt (Virtio) - and then export this to an NFS share.  VMware Converter can be used to perform a basic physical-to-virtual conversion of a running machine into "VMware Workstation" format, from which you can salvage VMDK-format disk images which qemu-img can convert to raw format.  You overwrite the dummy virtual disks in the exported RHEV VM with the converted ones, and then import the machine back into RHEV.  With a bit of post-conversion hacking you can excise all software related to physical hardware (e.g. OEM HP/Dell/IBM bloatware) and convert to paravirtualised NICs and disk controllers.  Yes, even for Windows VMs.

 

For converting physical RHEL machines to virtual ones, you could use a simpler and faster procedure involving bringing up your empty shell target VM in RHEL DVD rescue mode using a temporary IP address, and then pushing/pulling a tar backup of the source from/to the target via SSH or netcat, and manually installing the grub bootloader afterward.  Which, incidentally, is pretty much what VMware Converter does for RHEL conversions anyway.

 

Needless to say, all of this is a bit beyond your average punter.  Hence I think that Red Hat need to come up with something equivalent to VMware Converter for P2V conversions, if they want to avoid the embarassing position of referring customers to a competitor's (free) product.  Plus I'd like to see a automated conversion solution that makes less of a mess of RHEL conversions (have you seen what VMware Converter does with LVM-based source machines?  Ick!).

I think a P2V tool is absolutely necessary. I've used VMware Converter and been pleased with it; and being without such a tool, Red Hat may not find enough reason for customers to move. Especially in a time where lots of customers are moving from physical to virtual, it's even more necessary to have these tools now.

feature request; change in how Hyperviso network menu reacts.

Select a NIC in the network menu and press enter to configure it, now when you select 'back' it brings you back to the network menu entry on the left hand site, taking 7 extra tabs to get to the next NIC. So it would be nice, that after selecting 'back' you return to selected NIC on the network menu page.

What I'd like to see in the next version:

 

  •  a way to add vdisks from different storage domains to a VM via GUI (for example, use fast FC disks for Database files, but cheap storage for archive logs).
  •  a way to handle "direct LUN access" in the GUI ( has anyone ever done that? It is supposed to work via hooks, but i cannot find any information/Howto/description for that anywhere)
  •  as has been said before: Vdisk enlargement ist a must have!

FC Storage Support is quite new in the product, and I think it shows...

 

Other things:

  • Hotplug Disk/Net/CPU to VMs.
  • Make it easier to change theRHEV-M  VNC Console keyboard Settings (VNC console is practically unuseable with german keyboards). Either aks for it at setup time or describe it in post-installation.