Description of problem: There needs to be an additional chapter in the docs on both the localhost docs and the public facing docs.This chapter should contain the requirements for both the KVM host and the RHEV host that are described in the solutions article below [2]. =====//===== Requirements: A] Set up passwordless ssh between the vdsm user on the RHVH host and the root user on the KVM host as follows: 1) In RHVH host (the last command is a test): Raw # su -s /bin/bash vdsm # ssh-keygen # ssh-copy-id root@<KVM host> # virsh -c 'qemu+ssh://root@<KVMHOST>/system' list --all 2) On GUI 'import' used the URI as: qemu+ssh://root@/system username: root B] VM NICs must have MAC addresses within the range managed by the RHEV environment c] RAW SPARSE disks not supported D] Running VMs are ignored =====//===== See: [1] https://<RHEVM 4.0 HOSTNAME>/ovirt-engine/docs/manual/en-US/html/Virtual_Machine_Management_Guide/sect-Exporting_and_Importing_Virtual_Machines_and_Templates.html#Importing_the_virtual_machine_into_the_destination_data_center and [2] https://access.redhat.com/solutions/2712251 and [3] https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/single/virtual-machine-management-guide/#sect-Exporting_and_Importing_Virtual_Machines_and_Templates Version-Release number of selected component (if applicable):
I've got a draft mostly finished, but I have a few questions: 1. > # su -s /bin/bash vdsm > # ssh-keygen > # ssh-copy-id root@<KVM host> > # virsh -c 'qemu+ssh://root@<KVMHOST>/system' list --all The Xen procedure uses: # sudo -u vdsm ssh-keygen # sudo -u vdsm ssh-copy-id root.com # sudo -u vdsm ssh root.com Will both of these methods have the same outcome, or is one the preferred method? (I'd like to keep the steps consistent between procedures). 2. > B] VM NICs must have MAC addresses within the range managed by the RHEV > environment > c] RAW SPARSE disks not supported Do these limitations also apply to importing from Xen and VMware? 3. Is there a use case for unchecking Requires Authentication, or should that always remain checked?
*** Bug 1389044 has been marked as a duplicate of this bug. ***
> Description of problem: > There needs to be an additional chapter in the docs on both the localhost > docs and the public facing docs.This chapter should contain the requirements > for both the KVM host and the RHEV host that are described in the solutions > article below [2]. the article describes only one of the methods(the more complicated alternative, actually) so please make sure the document talks about both and stresses the intended default one using tcp+qemu
(In reply to Tahlia Richardson from comment #1) > I've got a draft mostly finished, but I have a few questions: > > 1. > > # su -s /bin/bash vdsm > > # ssh-keygen > > # ssh-copy-id root@<KVM host> > > # virsh -c 'qemu+ssh://root@<KVMHOST>/system' list --all > > The Xen procedure uses: > # sudo -u vdsm ssh-keygen > # sudo -u vdsm ssh-copy-id root.com > # sudo -u vdsm ssh root.com > > Will both of these methods have the same outcome, or is one the preferred > method? (I'd like to keep the steps consistent between procedures). I'd mention both, in both places. The Xen syntax would be preferred though, so perhaps something like: # sudo -u vdsm ssh-keygen # sudo -u vdsm ssh-copy-id root.com # virsh -c 'qemu+ssh://root@<HOST>/system' list --all and mention the ssh as a test to troubleshoot whether the keys were exchanged successfully (# sudo -u vdsm ssh root.com) if the last step fails, to identify if ssh keys or libvirt authentication is the problem > > 2. > > B] VM NICs must have MAC addresses within the range managed by the RHEV > > environment not sure where this came from. That is not true > > c] RAW SPARSE disks not supported > > Do these limitations also apply to importing from Xen and VMware? no. They should not apply to KVM either. Again not sure about source of this information > 3. > Is there a use case for unchecking Requires Authentication, or should that > always remain checked? it deserves mentioning that there is sucha thing as libvirt authentication, especially for KVM setups I expect people using custom KVM setups did spennd time to set it up authenticated and that accessing it on from RHEV host needs some adjustment(sharing the credentials, removing auth temporarily, opening TCP ports, etc). Too detailed to describe all options, but we should at least mention there are things to check/set
also, when docs point to other articles(e.g. https://access.redhat.com/articles/1351473) or mentiones a "virt-v2v" process it needs to be mentioned that for RHV KVM import that tool is _not_ used, there is a different oVirt/RHV specific one so generic RHEL-based documentation about libguestfs/virt-v2v is not applicable
(In reply to Michal Skrivanek from comment #4) > (In reply to Tahlia Richardson from comment #1) > > I've got a draft mostly finished, but I have a few questions: > > > > 1. > > > # su -s /bin/bash vdsm > > > # ssh-keygen > > > # ssh-copy-id root@<KVM host> > > > # virsh -c 'qemu+ssh://root@<KVMHOST>/system' list --all > > > > The Xen procedure uses: > > # sudo -u vdsm ssh-keygen > > # sudo -u vdsm ssh-copy-id root.com > > # sudo -u vdsm ssh root.com > > > > Will both of these methods have the same outcome, or is one the preferred > > method? (I'd like to keep the steps consistent between procedures). > > I'd mention both, in both places. The Xen syntax would be preferred though, > so perhaps something like: > # sudo -u vdsm ssh-keygen > # sudo -u vdsm ssh-copy-id root.com > # virsh -c 'qemu+ssh://root@<HOST>/system' list --all > and mention the ssh as a test to troubleshoot whether the keys were > exchanged successfully (# sudo -u vdsm ssh root.com) if the > last step fails, to identify if ssh keys or libvirt authentication is the > problem Thanks, I'll update that in both procedures. > > > > > 2. > > > B] VM NICs must have MAC addresses within the range managed by the RHEV > > > environment > > not sure where this came from. That is not true > > > > c] RAW SPARSE disks not supported > > > > Do these limitations also apply to importing from Xen and VMware? > > no. They should not apply to KVM either. Again not sure about source of this > information I'll leave these out for now, but given this came from a KCS solution, I assume these are things that GSS are encountering, so we may see more engineering and/or docs bugs about it. > > > > 3. > > Is there a use case for unchecking Requires Authentication, or should that > > always remain checked? > > it deserves mentioning that there is sucha thing as libvirt authentication, > especially for KVM setups I expect people using custom KVM setups did spennd > time to set it up authenticated and that accessing it on from RHEV host > needs some adjustment(sharing the credentials, removing auth temporarily, > opening TCP ports, etc). Too detailed to describe all options, but we should > at least mention there are things to check/set Just to confirm, those are things that you have to check/set when the Requires Authentication check box is unchecked? (So, keeping it checked is simpler, unless you need/want to use libvirt authentication). (In reply to Michal Skrivanek from comment #5) > also, when docs point to other articles(e.g. > https://access.redhat.com/articles/1351473) or mentiones a "virt-v2v" > process it needs to be mentioned that for RHV KVM import that tool is _not_ > used, there is a different oVirt/RHV specific one so generic RHEL-based > documentation about libguestfs/virt-v2v is not applicable Does this mean that the virt-v2v package does not need to be installed on the RHV Proxy Host? Is there any prerequisite for which host in the data center can be selected as the Proxy Host?
Now published at https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/single/virtual-machine-management-guide/#Importing_a_Virtual_Machine_from_KVM