Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

F Convert from other sources #34

Open
onenhansen opened this issue Jul 11, 2024 · 2 comments
Open

F Convert from other sources #34

onenhansen opened this issue Jul 11, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@onenhansen
Copy link
Contributor

Include a method to convert local OVF/OVA that have already been exported, have been asked about this multiple times.

@onenhansen onenhansen added the enhancement New feature or request label Jul 11, 2024
@onenhansen onenhansen self-assigned this Jul 11, 2024
@onenhansen onenhansen changed the title F Convert from local OVA/OVF F Convert from other sources Sep 24, 2024
@onenhansen
Copy link
Contributor Author

Changing title so the issue can include OVF/OVA import but also to allow migration from any source that virt-v2v is compatible with.

From https://libguestfs.org/virt-v2v-support.1.html at the time of writing:
Hypervisors (Input)

  • VMware ESXi - Must be managed by VMware vCenter ≥ 5.0 unless VDDK is available.
  • OVA exported from VMware - OVAs from other hypervisors will not work.
  • VMX from VMware - VMX files generated by other hypervisors will not work.
  • RHEL 5 Xen, SUSE Xen, Citrix Xen has not been recently tested.
  • Hyper-V - Not recently tested. Requires that you export the disk or use virt-p2v(1) on Hyper-V.
  • Direct from disk images - Only disk images exported from supported hypervisors, and using container formats supported by qemu.
  • Physical machines - Using the virt-p2v(1) tool.

@onenhansen
Copy link
Contributor Author

The idea here will be to separate out the stages of the conversion process into Modules which have a defined set of methods to handle the conversion from their particular source, ending in passing the metadata to the next stage, and leaving disks in the working directory to be added to OpenNebula.

This way we can just have a case which includes a different module in a Converter class based on which authentication information has been provided. I'll be using the f-34-all-sources branch for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant