similar to: OpenStack output - server_id

On Mon, Sep 24, 2018 at 6:30 PM Richard W.M. Jones <rjones@redhat.com> wrote: > On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote: > > Hi, > > Hi Fabien, sorry I didn't respond to this earlier as I was doing some > work. If you CC me on emails then you can usually get a quicker > response. > > > I've read the virt-v2v OpenStack output code

On my current instance, the meta_data.json is the following: { "availability_zone": "nova", "devices": [], "hostname": "ims-host-1", "keys": [ { "data": "ssh-rsa

On Tue, Sep 25, 2018 at 10:20:07AM +0200, Fabien Dupont wrote: > "uuid": "7ee62bdc-1c9d-4193-bb8f-fdbbbdfded0f" > } > > The information we need is the uuid. I don't have a way to test it, so this is only compile tested, however something like this? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming

Hi, There has been discussion about the OpenStack output and Richard asked for a public thread on this list, so here it is. For v2v from VMware to RHV, there is a Python script that does some extra steps to create the virtual machine after the disks have been converted. We want to have the same behavior for OpenStack, i.e. have virt-v2v create the instance once the volumes have been created.

New code tries SIGTERM first, with a grace period of 30 seconds: https://github.com/ManageIQ/manageiq-content/pull/433. On Wed, Sep 26, 2018 at 6:10 PM Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Sep 26, 2018 at 04:57:19PM +0200, Fabien Dupont wrote: > > It's not virt-v2v-wrapper that kills virt-v2v, it's ManageIQ. We have the > > PID from

On Wed, Sep 26, 2018 at 11:39 AM Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Sep 26, 2018 at 09:57:22AM +0200, Fabien Dupont wrote: > > Hi, > > > > There has been discussion about the OpenStack output and Richard asked > for > > a public thread on this list, so here it is. > > > > For v2v from VMware to RHV, there is a Python script that

On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote: > Hi, Hi Fabien, sorry I didn't respond to this earlier as I was doing some work. If you CC me on emails then you can usually get a quicker response. > I've read the virt-v2v OpenStack output code to understand how it works and > I've seen this: > > > (* The server name or UUID of the conversion

On Wed, Sep 26, 2018 at 4:25 PM Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Sep 26, 2018 at 02:40:54PM +0200, Fabien Dupont wrote: > > [Adding Tomas Golembiovsky] > > > > Well, that's mainly IMS related challenges. We're working on > > OpenStack output support and migration throttling and this implies > > changes to virt-v2v-wrapper.

Random old patch that I had in my queue. Posting it as a backup, it is still untested. Rich.

On Tue, 27 Feb 2018 13:43:59 +0100 Fabien Dupont <fdupont@redhat.com> wrote: > We can still find them and run the sysprep, but I have > the feeling that it would be more logical if virt-v2v did the sysprep when > target is oVirt / RHV. This is trickier than you think. For LVM volumes somebody (VDSM) has to lock and prepare the disks for you first and there is no external API to do

[Adding Tomas Golembiovsky] On Wed, Sep 26, 2018 at 12:11 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > Rather than jumping to a solution, can you explain what the problem > is that you're trying to solve? > > You need to do <X>, you tried virt-v2v, it doesn't do <X>, etc. > Well, that's mainly IMS related challenges. We're working on

In this case, shouldn't that be done by the upload-disk API ? When you upload a VM, oVirt knows what to do with it and handle the locking and any operations required to make the VM an oVirt VM. On 27 February 2018 at 13:53, Tomáš Golembiovský <tgolembi@redhat.com> wrote: > On Tue, 27 Feb 2018 13:43:59 +0100 > Fabien Dupont <fdupont@redhat.com> wrote: > > > We can

On Wed, Dec 5, 2018 at 12:01 PM Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > > This patch is just for discussion. There are still a couple of issues > > > that I'm trying to fix. > > > > Sorry if I missed the

Running sysprep is quite easy today because we use the export domain, which is frequently NFS. So we simply mount it on the conversion host and run sysprep against the disks of the converted VM before it is imported. Soon, we want to skip the export domain, so the disks of the VM will be in a separate domain. We can still find them and run the sysprep, but I have the feeling that it would be more

The first patch restricts passthrough parameters to ones matching "os-*". This was how it was documented, but not how it was implemented. The second patch is the same as v2 here: https://www.redhat.com/archives/libguestfs/2018-November/msg00187.html Rich.

This patch implements output to OpenStack Cinder volumes using OpenStack APIs. It has only been lightly tested, but appears to work. There are some important things to understand about how this works: (1) You must run virt-v2v in a conversion appliance running on top of OpenStack. And you must supply the name or UUID of this appliance to virt-v2v using the ‘-oo server-id=NAME|UUID’ parameter.

On Wed, Dec 05, 2018 at 01:18:49PM +0100, Fabien Dupont wrote: > On Wed, Dec 5, 2018 at 12:01 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > > > On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > > > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > > > This patch is just for discussion. There are still a couple of

v1 was here: https://www.redhat.com/archives/libguestfs/2018-August/thread.html#00287 v2: - The -oa option now gives an error; apparently Cinder cannot generally control sparse/preallocated behaviour, although certain Cinder backends can. - The -os option maps to Cinder volume type; suggested by Matt Booth. - Add a simple test.

On Wed, Dec 05, 2018 at 09:01:16AM +0000, Roman Kagan wrote: > On Tue, Dec 04, 2018 at 05:29:31PM +0000, Richard W.M. Jones wrote: > > This patch is just for discussion. There are still a couple of issues > > that I'm trying to fix. > > Sorry if I missed the original discussion on that, but why is copying > the static IP configuraition even considered to be a good

On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano wrote: > On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote: > > Remove ties to MAC address because it is likely to change. > > v2v tries to preserve the MAC address of network interfaces; few months > ago we did a fix regarding this: > https://bugzilla.redhat.com/show_bug.cgi?id=1506572 > > The