Bryan Kearney wrote: >> Hmm. I don't think that's a big deal now at all (since virt-install is >> already encoding all this stuff *anyway*). But I thought about it, and >> you're right. This could become very tricky in the future. >> >> However, there's still a problem I'm not sure how to deal with: general >> export. In this case we might not even be exporting to a format that >> libvirt can even *deal* with, never mind one that's on the other end of >> the connection. What do we do in this case? >> >> How can I export to .vmx without hard-coding some stuff based upon >> command-line options? Do we require a connection for this, and try to >> work out defaults based on the connection anyway? This is less >> than ideal: consider the poor user who's not booted under Xen, and wants >> to import his Xen VM into VMWare on that machine. > > I agree.. I could see a 2 very common use cases: > > 1) I am running on hypervisorX, and I get an image for hypervisor Y > which I want to play with. I should be able to convert Y to X without > having Y running in my enterprise. So if you download vmx and are on libvirt, you have an active connection available which you can pass to virt-convert. If you are on vmware and download libvirt, a connection won't be required for conversion so this also would work fine. > > 2) I am building appliances, and I want to support hypervisor Y. I > should be able to build for my internal X and then convert to Y. > >From the appliance perspective, portability is key. Unfortunately, libvirt domain xml is not portable. So the case of converting TO libvirt xml is not relevant here. So if you build a libvirt domain, you can then export to vmx or virt-image format without needing any special connections as mentioned above. So I think requiring the libvirt connection for domain xml export doesn't impede these use cases. - Cole _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
