similar to: libguestfs and RHEV

On Tue, May 07, 2013 at 05:26:14PM +0000, Davis, Richard wrote: > Apologies for the direct questioning, but is there a limit to the > amount of disks (virtio devices) assigned to VM that virt-v2v can > handle ? (I'm moving RHEL VM's from RH KVM hypervisors to RHEV > using virt-v2v-0.8.9-2.el6.x86_64) The published version of virt-v2v can only handle either 2 or 3 guest hard

From: Qixiang Wan <qwan at redhat.com> Commit 0973765674abd773ad04a99ddfdff8e81693e1ff introduced a regression which caused the OVF file not to be generated when outputting to RHEV. Fixes RHBZ#602067 --- lib/Sys/VirtV2V/Target/RHEV.pm | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Sys/VirtV2V/Target/RHEV.pm b/lib/Sys/VirtV2V/Target/RHEV.pm index

Store log from MSI installer. Log file will be located in firstboot scripts-done directory with name rhev-apt.log. The path has to be double-quoted to handle spaces in path name properly. Hopefully this can help resolve RHBZ#1584678 someday. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/convert_windows.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

RHEV will fail to start a guest with more than one VirtIO disk marked as bootable. The previous behaviour of V2V simply marked all disks as bootable, intending to follow the behaviour of libvirt's qemu driver. However, libvirt's qemu driver actually only marks the first disk specified in the domain XML (which may or may not be Xda) as bootable. This change updates the RHEV output to follow

I recently ran into some problems using certain oVirt (3.3) features on CentOS 6.4 hosts. The solution was to use the qemu-kvm-rhev version from the EL6 RHEV repository: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/qemu-kvm-rhev-0.12.1.2-2.355.el6_4.9.src.rpm It seems that this tree is not carried/built by CentOS. Are there any plans on the CentOS for carrying these

rmtree can die instead of returning failure under some circumstances. We don't want this to stop cleanup. --- lib/Sys/VirtV2V/Target/RHEV.pm | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/lib/Sys/VirtV2V/Target/RHEV.pm b/lib/Sys/VirtV2V/Target/RHEV.pm index 295c19d..c9add0c 100644 --- a/lib/Sys/VirtV2V/Target/RHEV.pm +++

The previous support documentation said that for UEFI guests, when using RHEL ≥ 7.3 host, you must use qemu-kvm-rhev. For RHEL 8 this is inaccurate since qemu-kvm-rhev no longer exists. Since 7.3 is now an obsolete version of RHEL 7 we can change the text to refer to RHEL 7 only: On RHEL 7, only qemu-kvm-rhev (not qemu-kvm) is supported. Thanks: Ming Xie. --- v2v/virt-v2v-support.pod | 2

On Wed, Dec 07, 2016 at 10:56:05AM +0100, Pino Toscano wrote: > On Wednesday, 7 December 2016 08:34:35 CET Richard W.M. Jones wrote: > > On Tue, Dec 06, 2016 at 04:41:52PM +0100, Pino Toscano wrote: > > > On Thursday, 1 December 2016 14:35:07 CET Richard W.M. Jones wrote: > > > > You can now use -o rhv (-o rhev is supported for compatibility). > > > >

I've been experiencing severe stability issues writing large amounts of data to an NFS export (I have never successfully written 8GB of data without having to reboot my machine). This patch alleviates the problem. I have successfully exported an 8GB disk with this patch in place. --- lib/Sys/VirtV2V/Target/RHEV.pm | 29 ++++++----------------------- 1 files changed, 6 insertions(+), 23

On Fri, Nov 22, 2013 at 09:42:28AM +0000, Исаев Виталий Анатольевич wrote: > Rich, you are right; the hypervisor is RHEV-H. As Itamar has just > explained me, hooks are executed on the hypervisor’s side (not on > the RHEV-M, as I used to think), so properly working libguestfs on > the RHEV-H will resolve my issue. This is a bug. I have filed this:

On Tue, Dec 06, 2016 at 04:41:52PM +0100, Pino Toscano wrote: > On Thursday, 1 December 2016 14:35:07 CET Richard W.M. Jones wrote: > > You can now use -o rhv (-o rhev is supported for compatibility). > > This LGTM -- the only concern is that "output:rhev" will disappear from > the machine-readable output (and thus potentially breaking users). > I have PoC for

Am Freitag, den 22.11.2013, 10:29 +0000 schrieb Исаев Виталий Анатольевич: > Thanks a lot. Yes, we have a Support and we will ask them to help with this bug. > > How do you think, maybe we can hack this issue quickly just putting the kernel file (desired by libguestfs) manually to some directory on the RHEV-H file system? /boot and /lib/modules do not contain kernels on RHEV-H. Hey,

----- Original Message ----- > From: "Richard W.M. Jones" <rjones@redhat.com> > To: "Исаев Виталий Анатольевич" <isaev@fintech.ru> > Cc: libguestfs@redhat.com > Sent: Tuesday, January 14, 2014 6:42:23 PM > Subject: Re: [Libguestfs] Libguestfs can't launch with one of the disk images in the RHEV cluster > > On Tue, Jan 14, 2014 at 02:57:35PM

On Wednesday, 7 December 2016 10:02:49 CET Richard W.M. Jones wrote: > Support for RHEV with RHEL 6 nodes required us to output the old style > qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been > supported as a RHEV node type. Since RHV 4.1, compat=1.1 is > supported. (Support for compat=1.1 is uncertain in RHV 4.0 even on > RHEL 7 nodes.) > > There are

Dear libguestfs developers, We are developing the protected enterprise system based on several Red Hat technologies (Red Hat Enterprise Virtualisation, the IdM server and so on). Our current goal is to prevent the booting of the virtual machine in case of integrity loss. So what we are trying to do Is to intercept the event of the VM's start (using the RHEV Manager hook scripts), mount the

Date formats were previously undefined in RHEV's OVF output. They are now defined as: 'yyyy/mm/dd hh:mm:ss'. This change updates dates output by virt-v2v to use the new format. --- lib/Sys/VirtV2V/Target/RHEV.pm | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/lib/Sys/VirtV2V/Target/RHEV.pm b/lib/Sys/VirtV2V/Target/RHEV.pm index

[CC to Fabian - can you comment on the ovirt-node problem below] On Thu, Nov 21, 2013 at 10:02:46PM +0000, Исаев Виталий Анатольевич wrote: > On 11/21/2013 05:56 PM, Richard W.M. Jones wrote: > > When you say "cannot access them" do you get an error message? Could > > it be an SELinux denial? > > Yes, when I am trying to open some logical volume on the hypervisor

Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. Since RHV 4.1, compat=1.1 is supported. Support for compat=1.1 is uncertain in RHV 4.0 even on RHEL 7 nodes. There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1). Therefore this

Cleanup was not happening properly if a migration to RHEV was killed prematurely with a Ctrl-C. Firstly, the SIGINT and SIGQUIT handlers were not being registered early enough in virt-v2v.pl. Secondly, if Ctrl-C killed the guestfs qemu process first it would deliver a SIGPIPE to v2v, which caused an unclean shutdown without cleanup. Fixes RHBZ#596015 --- v2v/virt-v2v.pl | 17 ++++++++++++++---

On 11/21/2013 05:56 PM, Richard W.M. Jones wrote: > [Adding Itamar: Any suggestions on where Vitaly could get help on this > RHEV-M API problem?] > > On Thu, Nov 21, 2013 at 02:27:08PM +0000, Исаев Виталий Анатольевич wrote: >> Dear libguestfs developers, >> >> We are developing the protected enterprise system based on several >> Red Hat technologies (Red Hat