John Levon wrote: > On Mon, Jul 14, 2008 at 12:55:23PM -0400, Cole Robinson wrote: > >> So I'm not generally opposed to this idea, however the way this patch >> implements it is a massive duplication of the virtinst apis, so >> NACK in this current form. > > I'm not sure it's "massive". Are you saying I should be using > setup_install, etc. to generate the XML? This will leave me with no > ability to modify what gets created, unless I'm misunderstanding you. > I admit I'm not very familiar with these APIs. > No, setup_install would not be neccessary. You could populate a Guest object with all the data imported from another format, and then call validate_parms and get_xml_config. Truthfully, virtinst as an API is a mess: It's been built incrementally from an interactive script that made xen guests. I've been thinking alot recently about ways to clean it up and really seperate all the pieces. That aside, It's main functions are as a way to build libvirt xml, and a way to simplify install processes like fetching tree kernels, setting up disks for cdrom booting, etc. In this case you would be ignoring all the install pieces and just using the objects to build the xml. > I don't want to use virt-image directly because of its > information-losing properties. I understand this, virt-image certainly isn't the thing to use unless portability is the specific goal. >> Like Dan mentioned before, if we allow converting to libvirt xml, we >> need to make it clear that the generated config is really only >> applicable on the machine it is generated. > > Surely, only applicable to machine it's generated on OR the connection it's > connected to, if one's provided? > Yes my statement was unclear, I meant to say "only applicable for the host the libvirt connection is on." >> A connection must be required in order to do the conversion so we can >> use the virtinst apis and check capabilities xml. > > I'm a bit unclear on the need for this to be a requirement. It just > seems to be placing unnecessary obstacles in the user's way. You're > basically turning the warning above into an error for many situations. > If we don't require using an active libvirt connection, we will find ourselves just duplicating information that is already presented by libvirt capabilities xml, such as emulator paths, feature availability like pae, and in the future, whitelists for device models, all with varying degrees of accuracy. Also, what is the usecase of converting to libvirt xml _without_ an active connection? If, lacking a connection, the best we can guarantee is "this xml will work on this physical machine", then the xml would only be useful if they have a libvirt setup on that physical machine, and if that's the case they can provide a uri to the app. Granted, having to specify a uri is annoying for a user, but we can choose sensible defaults and make this largely transparent, as virt-install currently does. > (Yes, I know I don't have a connection option yet, hopefully I'll be > adding this soon.) > > regards > john > Thanks, Cole _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
