How does the UI for this work in RHEV-M? Is the server/desktop determination made strictly based on the OS selected, or can the user select?

(In reply to comment #2)
> How does the UI for this work in RHEV-M? Is the server/desktop determination
> made strictly based on the OS selected, or can the user select?

there's a button to create a new desktop or server. the OS is selected afterwards.

(In reply to comment #3)
> (In reply to comment #2)
> > How does the UI for this work in RHEV-M? Is the server/desktop determination
> > made strictly based on the OS selected, or can the user select?
> 
> there's a button to create a new desktop or server. the OS is selected
> afterwards.

In that case I don't think we can base the selection strictly on detected OS. I think a command-line option would make sense here.

What would be a useful default if the user doesn't specify a type? Options I can think of are:

* Server
* Desktop
* Dependent on OS type
* Set per-site in the config file

I would extend the capability tag options in virt-v2v.conf, adding for example

vmtype=
the type of vm in term of capabilities
with possible values desktop, server, both

vmtypedef=
the default vmtype if not specified inside the virt-v2v command

A rh el 6 could contain
<capability os='linux' distro='rhel' major='6' name='virtio' vmtype='both' vmtypedef='server'/>

For w2k3:
<capability os='windows' major='5' minor='2' arch='i386' vmtype='server'>

For Wxp:
<capability os='windows' major='5' minor='1' arch='i386' vmtype='desktop'>

And then in virt-v2v a "-cap" option fro example

So if 
1) for an xp vm you run
virt-v2v -cap server ....
you will get an error and without the -cap you will get a desktop vm

2) for a w2k3 vm if you run
virt-v2v -cap desktop ...
you will get an error and without the -cap you will get a server vm

3) for a rh el 6 vm if you run
a) virt-v2v -cap desktop ...
you will get a desktop vm

b)  virt-v2v ... (without any -cap option)
you will get a server

AFAIK in VMware View, if it can serve as a reference for desktops, you can deploy only windws xp, windows vista and windows 7 systems. 
You cannot simply create w2k3 based desktop pools...
Probably you can create a w2k3 vm in vsphere, install on it the View client piece with its enhanced rdp protocol and broker related things and then manage it from within View, but to create a pool you probably have to create many w2k3 and group them manually in a pool... not OOTB anyway

just my 2eurocent...

BTW: In my opinion it is a sort of ambiguity that the key "name=virtio" appears for linux in "capability" tag, while for windows in "app" tag (with the "path" sub-tag).
Probably it could be changed to be consistent across archs...

Gianluca

Verified the bug with:
virt-v2v-0.8.6-1.el6.x86_64
libguestfs-1.16.2-1.el6.x86_64
libvirt-0.9.9-2.el6.x86_64
rhevm:ic154.1

Steps:
Run man virt-v2v,you can see parameter --vmtype has been added.
#man virt-v2v
  --vmtype type
           Specify the type of guest which will be created on a RHEV target. Options are desktop or server.

1.Use --vmtype to set vm type as desktop.
# virt-v2v  -ic qemu+ssh://10.66.72.122/system -o rhev -os 10.66.90.115:/vol/v2v_manual/nfs_export -n rhevm kvm-rhel6.1-x86_64 --vmtype desktop
kvm-rhel6.1-x86_64.img: 100% [====================================================================================]D 0h02m12s
virt-v2v: kvm-rhel6.1-x86_64 configured with virtio drivers.
2.After conversion,checked the VmType in ovf file:
<VmType>0</VmType>
3.Import the guest to rhevm,it displays as desktop.

Also use --vmtype to set vm type as server.
1.Use --vmtype to set vm type as server.
# virt-v2v  -ic qemu+ssh://10.66.72.122/system -o rhev -os 10.66.90.115:/vol/v2v_manual/nfs_export -n rhevm kvm-rhel6.1-x86_64-qcow2 --vmtype server
rhel6u1-64b-qcow2: 100% [=========================================================================================]D 0h01m24s
virt-v2v: kvm-rhel6.1-x86_64-qcow2 configured with virtio drivers.
2.After conversion,checked the VmType in ovf file:
<VmType>1</VmType>
3.Import the guest to rhevm,it displays as server.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
The customer is converting a guest to run on RHEV. The guest is a Desktop-type workload.

Consequence
The virt-v2v tool unconditionally marks all converted guests as a Server-type workload. This causes them to be displayed differently in RHEV-M.

Fix
virt-v2v has a new command line option, --vmtype, which will force the conversion process to mark the newly created RHEV VM as either Desktop or Server. If --vmtype is omitted, virt-v2v guesses the type based on the guest operating system as follows:

Windows XP, Vista, 7: Desktop
Windows 2003, 2008: Server
RHEL ES, AS, Server, 2.1: Server
RHEL WS, Desktop, Client: Desktop
Fedora: Desktop
Linux (except RHEL and Fedora): Server

Result
The user can choose either Desktop or Server during the conversion process. If they don't choose explicitly, the result will be either Desktop or Server as defined above.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0788.html