Bug 1049604

while doesn't solve all use cases, if you can inject it to an nfs storage domain in the right format, you can 'register' the disk (not the vm) to the engine.

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

I'd like to reopen this as this is a relevant issue for most users ("attaching
a whole esxi server" or "adding a disk onto nfs in the right format" are _not_ user friendly at all).

I'm not aware that anything changed in recent released versions or master.

kind regards

Sven

We're tracking this functional requirement under bug 1091377. 
(Also, see the corresponding RHEV bug 1122970 which is a bit more fleshed out, and also addresses details regarding images vs. ISOs)

*** This bug has been marked as a duplicate of bug 1091377 ***

Seems that bug 1091377 is about adding ISOs, but there's an
obvious demand for uploading virtual machines.  People are using
the old virt-v2v for this.  In the new virt-v2v I (quite
deliberately) removed the ability to use it as an upload tool
for working around missing functionality in oVirt.

I also can not see how this is a dup of bz #1091377

as Richard already mentioned:

This is about whole vms uploads, containing disks and config files.

Like: "Import me this vmware vm", "virtualbox", "kvm(virt-manager)" etc.

Maybe this could be split into sub-bugs for the different targets.

(In reply to Sven Kieske from comment #6)
> I also can not see how this is a dup of bz #1091377
> 
> as Richard already mentioned:
> 
> This is about whole vms uploads, containing disks and config files.
> 
> Like: "Import me this vmware vm", "virtualbox", "kvm(virt-manager)" etc.

Well yes and no.

If you want to import VMware, then use virt-v2v.

There is no way to import VirtualBox VMs.

If you want to import a KVM (virt-manager) VM then there is
missing functionality in oVirt, and I don't believe that
bug 1091377 covers that missing functionality.

(In reply to Richard W.M. Jones from comment #7)
> (In reply to Sven Kieske from comment #6)
> > I also can not see how this is a dup of bz #1091377
> > 
> > as Richard already mentioned:
> > 
> > This is about whole vms uploads, containing disks and config files.
> > 
> > Like: "Import me this vmware vm", "virtualbox", "kvm(virt-manager)" etc.
> 
> Well yes and no.
> 
> If you want to import VMware, then use virt-v2v.
> 
> There is no way to import VirtualBox VMs.
> 
> If you want to import a KVM (virt-manager) VM then there is
> missing functionality in oVirt, and I don't believe that
> bug 1091377 covers that missing functionality.

The discussion here has uncovered some nuances not explicitly covered in the bug 1091377 and bug 1122970.  We'd like to explore vm upload (ova, vmdk, etc) in the later phases of the project encompassing bug 1091377, so in light of all that: let's leave this open as a dependent bug and revisit it once we have the iso/image functionality in oVirt.

While I am just a humble user of the community version of the software modules involved (yeah, that's a fancy way to say non-paying user :D) please allow me chime in and support the idea that there should be a simpler and more elegant way to import pre-existing virtual images into ovirt without shovelling it through the configuration backdoor. 
ESX&friends have a big advantage at this.
The simplest usage scenario for this would be migrating from simpler setups with libvirt+kvm to ovirt. When you have images of hundreds of GB running various conversion tools on those images is PITA, especially if the image is already just a raw sparse file that needs no conversion. You need to be able to define some virtual machine and say to it "ok, just mount (use) these images i provide and that already exist on the NFS  repository, don't alter them, dont convert them, just register them as part of virtual machine X"
Having another feature to create a virtual machine based on a libvirt definition xml would be nice, but that would not be as useful as registering just the disk image. That is because defining a virtual machine with the same parameters (memory,cpu...) exactly like the one I am migrating takes 5 minutes, while converting/importing the whole shebang that includes the vm image conversion can take way way longer (and also probably way more disk space).

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
anymore.
Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still
an issue.

Opening again.  Please modify your script so it doesn't close
RFE bugs.

I wrote a smallish script to do this:

http://git.annexia.org/?p=import-to-ovirt.git;a=summary

It's not a replacement for having this feature added to oVirt,
but can be used as a workaround.

This script is not supported by Red Hat.

(In reply to Richard W.M. Jones from comment #13)
> I wrote a smallish script to do this:
> 
> http://git.annexia.org/?p=import-to-ovirt.git;a=summary
> 
> It's not a replacement for having this feature added to oVirt,
> but can be used as a workaround.
> 
> This script is not supported by Red Hat.

Wonderful! I was able to import a Ubuntu-based .ova (graylog) into oVirt using this tool. I followed steps C and D at http://www.ovirt.org/Vm_migration_from_vmware to get the ova into kvm compatible mode. This tool worked like a charm to move the qcow2 into the esd.

I was figuring that I would have to write an .ovf by hand or manually migrate my services to servers in oVirt. You have saved me at least 200 hours worth of work!!!

*** Bug 1263787 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 1319758 ***

This is upload the other is download. Why did you close as dup?

Mea culpa. Did not realize this small difference.

Can the bug move to MODIFIED?

(In reply to Yaniv Kaul from comment #27)
> Can the bug move to MODIFIED?

Unfortunately, not yet. There is a good progress but the basics are not in yet.

(In reply to Arik from comment #28)
> (In reply to Yaniv Kaul from comment #27)
> > Can the bug move to MODIFIED?
> 
> Unfortunately, not yet. There is a good progress but the basics are not in
> yet.

I assume it should be moved to 4.2.1?

(In reply to Yaniv Kaul from comment #29)
> I assume it should be moved to 4.2.1?

Yes

Verification builds:
rhvm-4.2.2.6-0.1.el7
libvirt-client-3.9.0-14.el7_5.2.x86_64
qemu-kvm-rhev-2.10.0-21.el7_5.1.x86_64
sanlock-3.6.0-1.el7.x86_64
vdsm-4.20.23-1.el7ev.x86_64
virt-v2v-1.36.10-6.el7.x86_64

Polarion test plan added to external trackers

This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE.

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