Guido Günther wrote: > On Mon, Mar 02, 2009 at 07:50:28PM +0000, Daniel P. Berrange wrote: >> On Mon, Mar 02, 2009 at 08:12:03PM +0100, Guido G?nther wrote: >>> Hi Cole, >>> this all looks great. >>> On Fri, Feb 27, 2009 at 05:50:15PM -0500, Cole Robinson wrote: >>>> The summary section is pretty straight forward, no surprises here. >>>> The 'Advanced Options' section encompasses networking, hypervisor, and >>>> architecture options. The hypervisor and arch defaults were explained above. >>> An option to select disk (scsi, ide, virtio) and network adapter model >>> (e1000, ...) as advanced options would be great (still defaulting to >>> virtio if supported via the osdict) since there are some OSes that don't >>> support all hardware out of the box and there are kvm/qemu versions that >>> have problems with certain adapter types. >> If there are combinations of OS,Disk that don't work IMHO we should >> improve the OS type metadata so we don't use them. Choice of specific >> hardware models is something we really want to keep out of the new VM >> wizard, because the end user really isn't in a position to have the >> knowledge to make suitable choices. > Sometimes it's not an issue of the guest but of the hypervisor like > missing PXE roms[1]. Attached is a patch Andreas Unterkircher that adds > NIC model selection to the advanced options of the vm wizard (some code > could probably be shared with vmmAddHardware). > Cheers, > -- Guido > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521091 > Ideally this is the type of issue the OS metadata should still be able to solve, though we are far from it at the moment. Rather than adding on more UI to the 'New VM' wizard, the more general solution to problems like this is to allow a way to customize the VM before starting the install. My thought is that we can drop the user into the VM Details view, where they will then have all the functionality currently exposed by the add/remove hardware wizard. WRT the above issue, since I committed your patch to allow specifying model via virt-install, I think that's a reasonable workaround till the virt-manager work is done. Thanks, Cole _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
