Re: [Libguestfs] VM name starting with a dash

2023-04-04 Thread Tomáš Golembiovský
On Mon, Apr 03, 2023 at 01:28:14PM +0100, Richard W.M. Jones wrote:
> 
> 13:19 < tgolembi[m]> is there a trick how to convert a VM with name that 
> starts with a dash? It's being confused for virt-v2v argument. 
>  :)
> 
> Yes you can do this:
> 
> $ virt-v2v -o [etc...] -- vmname

Duh. I didn't see that in the documentation and it didn't occur to me
to try. 

Thanks

> 
> Note all -options need to come before the "--".
> 
> For example:
> 
> $ virt-builder fedora-35
> $ mv fedora-35.img ./-fedora-35.img 
> $ virt-v2v -i disk -o null -- -fedora-35.img 
> [   0.0] Setting up the source: -i disk -fedora-35.img
> [etc]
> 
> It's quite possible this could hit other corner-cases inside virt-v2v
> (eg when running subprocesses), so if you see bugs please file them.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs



[Libguestfs] [v2v PATCH v3] -o rhv-upload: wait for VM creation task

2022-04-20 Thread Tomáš Golembiovský
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion. This will also help to prevent some corner case
scenarios (that would be difficult to debug) when the VM creation job
fails after virt-v2v already termintates with success.

Thanks: Nir Soffer
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1985827
Signed-off-by: Tomáš Golembiovský 
Reviewed-by: Arik Hadas 
Reviewed-by: Nir Soffer 
---
 output/rhv-upload-createvm.py | 57 ++-
 .../ovirtsdk4/__init__.py | 10 +++-
 .../ovirtsdk4/types.py| 19 +++
 3 files changed, 84 insertions(+), 2 deletions(-)

Changes in v3:

- this time really increased sleep and decreased timeout

diff --git a/output/rhv-upload-createvm.py b/output/rhv-upload-createvm.py
index 50bb7e34..8887c52b 100644
--- a/output/rhv-upload-createvm.py
+++ b/output/rhv-upload-createvm.py
@@ -19,12 +19,54 @@
 import json
 import logging
 import sys
+import time
+import uuid
 
 from urllib.parse import urlparse
 
 import ovirtsdk4 as sdk
 import ovirtsdk4.types as types
 
+
+def debug(s):
+if params['verbose']:
+print(s, file=sys.stderr)
+sys.stderr.flush()
+
+
+def jobs_completed(system_service, correlation_id):
+jobs_service = system_service.jobs_service()
+
+try:
+jobs = jobs_service.list(
+search="correlation_id=%s" % correlation_id)
+except sdk.Error as e:
+debug(
+"Error searching for jobs with correlation id %s: %s" %
+(correlation_id, e))
+# We don't know, assume that jobs did not complete yet.
+return False
+
+# STARTED is the only "in progress" status, anything else means the job
+# has already terminated.
+if all(job.status != types.JobStatus.STARTED for job in jobs):
+failed_jobs = [(job.description, str(job.status))
+   for job in jobs
+   if job.status != types.JobStatus.FINISHED]
+if failed_jobs:
+raise RuntimeError(
+"Failed to create a VM! Failed jobs: %r" % failed_jobs)
+return True
+else:
+running_jobs = [(job.description, str(job.status)) for job in jobs]
+debug("Some jobs with correlation id %s are running: %s" %
+  (correlation_id, running_jobs))
+return False
+
+
+# Seconds to wait for the VM import job to complete in oVirt.
+timeout = 3 * 60
+
 # Parameters are passed in via a JSON doc from the OCaml code.
 # Because this Python code ships embedded inside virt-v2v there
 # is no formal API here.
@@ -67,6 +109,7 @@ system_service = connection.system_service()
 cluster = 
system_service.clusters_service().cluster_service(params['rhv_cluster_uuid'])
 cluster = cluster.get()
 
+correlation_id = str(uuid.uuid4())
 vms_service = system_service.vms_service()
 vm = vms_service.add(
 types.Vm(
@@ -77,5 +120,17 @@ vm = vms_service.add(
 data=ovf,
 )
 )
-)
+),
+query={'correlation_id': correlation_id},
 )
+
+# Wait for the import job to finish.
+endt = time.monotonic() + timeout
+while True:
+time.sleep(10)
+if jobs_completed(system_service, correlation_id):
+break
+if time.monotonic() > endt:
+raise RuntimeError(
+"Timed out waiting for VM creation!"
+" Jobs still running for correlation id %s" % correlation_id)
diff --git a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py 
b/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py
index 0d8f33b3..e33d0714 100644
--- a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py
+++ b/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py
@@ -59,6 +59,9 @@ class SystemService(object):
 def disks_service(self):
 return DisksService()
 
+def jobs_service(self):
+return JobsService()
+
 def image_transfers_service(self):
 return ImageTransfersService()
 
@@ -104,6 +107,11 @@ class DisksService(object):
 return DiskService(disk_id)
 
 
+class JobsService(object):
+def list(self, search=None):
+return [types.Job()]
+
+
 class ImageTransferService(object):
 def __init__(self):
 self._finalized = False
@@ -135,7 +143,7 @@ class StorageDomainsService(object):
 
 
 class VmsService(object):
-def add(self, vm):
+def add(self, vm, query=None):
 return vm
 
 def list(self, search=None):
diff --git a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/types.py 
b/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/types.py
index 5707fa3e..38d89573 100644
--- a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/types.py
+++ b/tests/t

[Libguestfs] [v2v PATCH v2] -o rhv-upload: wait for VM creation task

2022-04-20 Thread Tomáš Golembiovský
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion. This will also help to prevent some corner case
scenarios (that would be difficult to debug) when the VM creation job
fails after virt-v2v already termintates with success.

Thanks: Nir Soffer
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1985827
Signed-off-by: Tomáš Golembiovský 
Reviewed-by: Arik Hadas 
Reviewed-by: Nir Soffer 
---
 output/rhv-upload-createvm.py | 57 ++-
 .../ovirtsdk4/__init__.py | 10 +++-
 .../ovirtsdk4/types.py| 19 +++
 3 files changed, 84 insertions(+), 2 deletions(-)


Changes in v2:

- fixed tests
- changes suggested by Nir
- increased sleep time and decreased timeout


diff --git a/output/rhv-upload-createvm.py b/output/rhv-upload-createvm.py
index 50bb7e34..642f0720 100644
--- a/output/rhv-upload-createvm.py
+++ b/output/rhv-upload-createvm.py
@@ -19,12 +19,54 @@
 import json
 import logging
 import sys
+import time
+import uuid
 
 from urllib.parse import urlparse
 
 import ovirtsdk4 as sdk
 import ovirtsdk4.types as types
 
+
+def debug(s):
+if params['verbose']:
+print(s, file=sys.stderr)
+sys.stderr.flush()
+
+
+def jobs_completed(system_service, correlation_id):
+jobs_service = system_service.jobs_service()
+
+try:
+jobs = jobs_service.list(
+search="correlation_id=%s" % correlation_id)
+except sdk.Error as e:
+debug(
+"Error searching for jobs with correlation id %s: %s" %
+(correlation_id, e))
+# We don't know, assume that jobs did not complete yet.
+return False
+
+# STARTED is the only "in progress" status, anything else means the job
+# has already terminated.
+if all(job.status != types.JobStatus.STARTED for job in jobs):
+failed_jobs = [(job.description, str(job.status))
+   for job in jobs
+   if job.status != types.JobStatus.FINISHED]
+if failed_jobs:
+raise RuntimeError(
+"Failed to create a VM! Failed jobs: %r" % failed_jobs)
+return True
+else:
+running_jobs = [(job.description, str(job.status)) for job in jobs]
+debug("Some jobs with correlation id %s are running: %s" %
+  (correlation_id, running_jobs))
+return False
+
+
+# Seconds to wait for the VM import job to complete in oVirt.
+timeout = 5 * 60
+
 # Parameters are passed in via a JSON doc from the OCaml code.
 # Because this Python code ships embedded inside virt-v2v there
 # is no formal API here.
@@ -67,6 +109,7 @@ system_service = connection.system_service()
 cluster = 
system_service.clusters_service().cluster_service(params['rhv_cluster_uuid'])
 cluster = cluster.get()
 
+correlation_id = str(uuid.uuid4())
 vms_service = system_service.vms_service()
 vm = vms_service.add(
 types.Vm(
@@ -77,5 +120,17 @@ vm = vms_service.add(
 data=ovf,
 )
 )
-)
+),
+query={'correlation_id': correlation_id},
 )
+
+# Wait for the import job to finish.
+endt = time.monotonic() + timeout
+while True:
+time.sleep(1)
+if jobs_completed(system_service, correlation_id):
+break
+if time.monotonic() > endt:
+raise RuntimeError(
+"Timed out waiting for VM creation!"
+" Jobs still running for correlation id %s" % correlation_id)
diff --git a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py 
b/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py
index 0d8f33b3..e33d0714 100644
--- a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py
+++ b/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py
@@ -59,6 +59,9 @@ class SystemService(object):
 def disks_service(self):
 return DisksService()
 
+def jobs_service(self):
+return JobsService()
+
 def image_transfers_service(self):
 return ImageTransfersService()
 
@@ -104,6 +107,11 @@ class DisksService(object):
 return DiskService(disk_id)
 
 
+class JobsService(object):
+def list(self, search=None):
+return [types.Job()]
+
+
 class ImageTransferService(object):
 def __init__(self):
 self._finalized = False
@@ -135,7 +143,7 @@ class StorageDomainsService(object):
 
 
 class VmsService(object):
-def add(self, vm):
+def add(self, vm, query=None):
 return vm
 
 def list(self, search=None):
diff --git a/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/types.py 
b/tests/test-v2v-o-rhv-upload-module/ovirtsdk4/types.py
index 5707fa3e..38d89573 100644
--- a/tests/test-v2v-o-rhv-upload-module/ovirt

Re: [Libguestfs] [PATCH] -o rhv-upload: wait for VM creation task

2022-04-13 Thread Tomáš Golembiovský
On Tue, Apr 12, 2022 at 08:34:27PM +0200, Tomáš Golembiovský wrote:
> oVirt API call for VM creation finishes before the VM is actually
> created. Entities may be still locked after virt-v2v terminates and if
> user tries to perform (scripted) actions after virt-v2v those operations
> may fail. To prevent this it is useful to monitor the task and wait for
> the completion. This will also help to prevent some corner case
> scenarios (that would be difficult to debug) when the VM creation job
> fails after virt-v2v already termintates with success.
> 

Forgot to mention this is related to bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1985827


> Thanks: Nir Soffer
> Signed-off-by: Tomáš Golembiovský 
> Reviewed-by: Arik Hadas 
> ---
>  output/rhv-upload-createvm.py | 57 ++-
>  1 file changed, 56 insertions(+), 1 deletion(-)

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs


[Libguestfs] [PATCH] -o rhv-upload: wait for VM creation task

2022-04-12 Thread Tomáš Golembiovský
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion. This will also help to prevent some corner case
scenarios (that would be difficult to debug) when the VM creation job
fails after virt-v2v already termintates with success.

Thanks: Nir Soffer
Signed-off-by: Tomáš Golembiovský 
Reviewed-by: Arik Hadas 
---
 output/rhv-upload-createvm.py | 57 ++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/output/rhv-upload-createvm.py b/output/rhv-upload-createvm.py
index 50bb7e34..c6a6fbd6 100644
--- a/output/rhv-upload-createvm.py
+++ b/output/rhv-upload-createvm.py
@@ -19,12 +19,54 @@
 import json
 import logging
 import sys
+import time
+import uuid
 
 from urllib.parse import urlparse
 
 import ovirtsdk4 as sdk
 import ovirtsdk4.types as types
 
+
+def debug(s):
+if params['verbose']:
+print(s, file=sys.stderr)
+sys.stderr.flush()
+
+
+def jobs_completed(system_service, correlation_id):
+jobs_service = system_service.jobs_service()
+
+try:
+jobs = jobs_service.list(
+search="correlation_id=%s" % correlation_id)
+except sdk.Error as e:
+debug(
+"Error searching for jobs with correlation id %s: %s" %
+(correlation_id, e))
+# We dont know, assume that jobs did not complete yet.
+return False
+
+# STARTED is the only "in progress" status, other mean the job has
+# already terminated
+if all(job.status != types.JobStatus.STARTED for job in jobs):
+failed_jobs = [(job.description, str(job.status))
+   for job in jobs
+   if job.status != types.JobStatus.FINISHED]
+if failed_jobs:
+raise RuntimeError(
+"Failed to create a VM! Failed jobs: %r" % failed_jobs)
+return True
+else:
+jobs_status = [(job.description, str(job.status)) for job in jobs]
+debug("Some jobs with correlation id %s are running: %s" %
+  (correlation_id, jobs_status))
+return False
+
+
+# Seconds to wait for the VM import job to complete in oVirt.
+timeout = 5 * 60
+
 # Parameters are passed in via a JSON doc from the OCaml code.
 # Because this Python code ships embedded inside virt-v2v there
 # is no formal API here.
@@ -67,6 +109,7 @@ system_service = connection.system_service()
 cluster = 
system_service.clusters_service().cluster_service(params['rhv_cluster_uuid'])
 cluster = cluster.get()
 
+correlation_id = str(uuid.uuid4())
 vms_service = system_service.vms_service()
 vm = vms_service.add(
 types.Vm(
@@ -77,5 +120,17 @@ vm = vms_service.add(
 data=ovf,
 )
 )
-)
+),
+query={'correlation_id': correlation_id},
 )
+
+# Wait for the import job to finish
+endt = time.time() + timeout
+while True:
+time.sleep(1)
+if jobs_completed(system_service, correlation_id):
+break
+if time.time() > endt:
+raise RuntimeError(
+"Timed out waiting for VM creation!"
+" Jobs still running for correlation id %s" % correlation_id)
-- 
2.35.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs


Re: [Libguestfs] Crafted OVAs and handling non-existing (empty) disks in OVF

2021-02-23 Thread Tomáš Golembiovský
On Mon, Feb 22, 2021 at 04:45:09PM +, Richard W.M. Jones wrote:
> On Mon, Feb 22, 2021 at 02:51:32PM +0100, Tomáš Golembiovský wrote:
> > Hi,
> > 
> > from time to time we get a request [1] to import appliance with crafted
> > OVF (from Cisco or Gigamon) into oVirt. The common denominator is that
> > some disks are missing and are supposed to be created during import of
> > the appliance.
> > 
> > Doing the import properly would require not only solving of the problem
> > with missing disks, but also implementing multiple concepts -- notably
> > concept of configurations [2] (for Cisco appliance) or concept of
> > properties [3] (for Gigamon appliance). This would be quite complex
> > change to oVirt as well as to virt-v2v and at the moment we don't feel
> > that such effort is justifiable. But by solving the problem with disks
> > we can at least provide a helping hand to those requiring the crafted
> > appliances. 
> 
> Some immediate questions: Can virt-v2v do anything useful for these
> appliances?

Probably same as for any foreign Linux VM. The Cisco appliance is
RHEL 7. I don't have access to the Gigamon appliance but from
metadata it looks like some CentOS.

> Does libguestfs inspection find anything inside the
> appliances?

I am not sure what you are asking here.

> Is installing virtio drivers useful? Do they not have virtio drivers
> already?

It is (fairly recent) Linux, so there's no need to install anything.
But if you're asking if it makes sense for the appliance to switch to
virtio devices then I would say yes.

> Where are they supposed to run originally?

On VMware.

Tomas

> 
> > The idea here is that virt-v2v would ignore the non-existing disks and
> > user would be required to add those manually after conversion. As for
> > OVFs using the configurations virt-v2v would pick some settings from OVF
> > (random from users perspective) and user would be responsible for
> > editing the VM's configuration after conversion (CPUs, memory, etc.) to
> > size the VM properly based on the expected use. We could further
> > constrain this to only work with -o vdsm, but this may not be needed
> > unless we hit some issues with implementing the feature. It is also
> > possible that ignoring the disks may not work for some reasons that
> > we have not yet discovered and we'll se once we try.
> > 
> > There is one more problem with the Cisco OVA that it contains .cert file
> > which is not specified in manifest. But the file is not needed during
> > conversion. So this could be possibly handled by enforcing virt-v2v to
> > use only files listed in manifest instead of complaining.
> > 
> > Before I invest any time into this I wanted to make sure that such
> > approach would be acceptable to the upstream. So would this be good
> > enough?
> 
> Does the proposed virt-v2v split help here?
> 
> https://listman.redhat.com/archives/libguestfs/2020-November/msg00022.html
> 
> With this kind of split, you could set up the disks however you liked
> -- for example creating dummy input disks (nbdkit-null-plugin
> instances probably) -- for the missing disks.  Then run just the
> virt-v2v conversion component to carry out the conversion.
> 
> Rich.
> 
> > ***
> > 
> > The topics for discussions are above. What follows are the technical
> > details for those interested in gain deeper understanding of the
> > problem. You may be wondering why would we want to ignore the empty
> > disks if we can create them for most of the output backends. The problem
> > is, that we cannot. Either we don't know which disks are of the interest
> > because not all should be used (configurations) or we have no idea how
> > big the disk should be (properties).
> > 
> > ###  Configurations
> > 
> > The OVF can define several configurations in DeploymentOptionSection.
> > A short (simplified) example may look like this:
> > 
> > 
> > 
> > 
> > ...
> > 
> > 
> > Then in the VirtualHardwareSection there can be duplicate settings
> > distinguished only by the ovf:configuration attribute. For example 2 
> > different
> > vCPU configurations:
> > 
> > 
> > ...
> > Number of Virtual CPUs
> > 3
> > 4
> > 
> > 
> > ...
> > Number of Virtual CPUs
> > 3
> > 16
> > 
> > 
> > In terms of disks this means that only some of the disks get used. 
> > Specifically
> > the Cisco Appliance has 4 disks listed in the DiskSec

[Libguestfs] Crafted OVAs and handling non-existing (empty) disks in OVF

2021-02-22 Thread Tomáš Golembiovský
Hi,

from time to time we get a request [1] to import appliance with crafted
OVF (from Cisco or Gigamon) into oVirt. The common denominator is that
some disks are missing and are supposed to be created during import of
the appliance.

Doing the import properly would require not only solving of the problem
with missing disks, but also implementing multiple concepts -- notably
concept of configurations [2] (for Cisco appliance) or concept of
properties [3] (for Gigamon appliance). This would be quite complex
change to oVirt as well as to virt-v2v and at the moment we don't feel
that such effort is justifiable. But by solving the problem with disks
we can at least provide a helping hand to those requiring the crafted
appliances. 

The idea here is that virt-v2v would ignore the non-existing disks and
user would be required to add those manually after conversion. As for
OVFs using the configurations virt-v2v would pick some settings from OVF
(random from users perspective) and user would be responsible for
editing the VM's configuration after conversion (CPUs, memory, etc.) to
size the VM properly based on the expected use. We could further
constrain this to only work with -o vdsm, but this may not be needed
unless we hit some issues with implementing the feature. It is also
possible that ignoring the disks may not work for some reasons that
we have not yet discovered and we'll se once we try.

There is one more problem with the Cisco OVA that it contains .cert file
which is not specified in manifest. But the file is not needed during
conversion. So this could be possibly handled by enforcing virt-v2v to
use only files listed in manifest instead of complaining.

Before I invest any time into this I wanted to make sure that such
approach would be acceptable to the upstream. So would this be good
enough?


***

The topics for discussions are above. What follows are the technical
details for those interested in gain deeper understanding of the
problem. You may be wondering why would we want to ignore the empty
disks if we can create them for most of the output backends. The problem
is, that we cannot. Either we don't know which disks are of the interest
because not all should be used (configurations) or we have no idea how
big the disk should be (properties).

###  Configurations

The OVF can define several configurations in DeploymentOptionSection.
A short (simplified) example may look like this:




...


Then in the VirtualHardwareSection there can be duplicate settings
distinguished only by the ovf:configuration attribute. For example 2 different
vCPU configurations:


...
Number of Virtual CPUs
3
4


...
Number of Virtual CPUs
3
16


In terms of disks this means that only some of the disks get used. Specifically
the Cisco Appliance has 4 disks listed in the DiskSection -- 1 system disk A
and 3 empty disks B,C,D. But the created VM never has all four. It has either
only A or it has A+B or A+C or A+D. Without understanding configurations we
cannot tell whether to use B, C, D or none.


###  Properties

The OVF can define various properties in ProductSection element. Like this:



...

02. Size of Data Disk
The size of the Data Disk in gigabytes.


...

...

...


And as before, without understanding the concept virt-v2v has no idea
how to size the disk. The Value element is optional (if the property is
userConfigurable) so relying on the default in OVF may not work. I can
imagine some OVFs may even use a property to specify vCPU count or
memory which could bring up a question how to handle those. Possibly
default to 0 or 1 (where 1 may be better default in my opinion).

Tomas


[1] https://bugzilla.redhat.com/1705600
[2] Open Virtualization Format Specification (DSP0243) Version 2.1.1,
Chapter 9.8 -- DeploymentOptionSection
[3] Open Virtualization Format Specification (DSP0243) Version 2.1.1,
Chapter 9.5.1 -- Property elements

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH] ovf: Try to set BiosType correctly according to the oVirt sources.

2020-12-07 Thread Tomáš Golembiovský
Hi,

On Fri, Dec 04, 2020 at 12:53:06PM +, Richard W.M. Jones wrote:
> Tomas, what do you think about this?
> 
> As far as I can tell we are not setting the BiosType correctly in any
> current scenario.

Yes, we are.

> Mostly we set it to "0" (cluster default), and I
> guess we can get away with that most of the time.  For UEFI guests we
> set it to "2" which simply seems wrong.
> 
> The patch tries to adjust the BiosType so it actually matches what the
> oVirt source code says.

It's not really intuitive (not to mention undocumented), but there is a
difference from what oVirt reads from OVF and how the Bios types are
represented internally. Basically all values are shifted by one. See the
'+1' in [1]. The change corresponding to the hack is here [2].

When they introduced cluster default in 4.4 development they did not
realize it is used also by others. When we spotted the mistake it was
already quite late and changing the enum to the original state was
already out of question. So this hack was born.

If virt-v2v wanted to set it to cluster default it can be done by
omitting  element altogether or by setting custom="false"
attribute. Specifying negative value for  should also work but
I'd rather not rely on that.

[1] 
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfReader.java#L699
[2] https://gerrit.ovirt.org/c/ovirt-engine/+/106692

> 
> Am I missing something?
> 
> Rich.
> 
> 

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v2v] v2v: windows: Fix schtasks /SD parameter.

2020-11-30 Thread Tomáš Golembiovský
On Mon, Nov 30, 2020 at 09:13:31AM +, Richard W.M. Jones wrote:
> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1895323
> ---
>  v2v/convert_windows.ml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

LGTM

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs



Re: [Libguestfs] About libguestfs python3.6 command execution

2020-11-30 Thread Tomáš Golembiovský
> > http://paste.openstack.org/show/800517/

This won't solve your issue with being unable to execute /bin/sh, but
the above does not work like that. You need to first add at least one
disk and then run the libguestfs appliance:

>>> import guestfs
>>> g = guestfs.GuestFS(python_return_dict=True)
>>> g.add_drive("my-machine.qcow2")
>>> g.launch()
>>> g.list_filesystems()
{'/dev/sda1': 'xfs'}
>>> g.mount('/dev/sda1', '/')
>>> g.sh("test 1 == 1")
''
>>> g.sh("echo yes")
'yes\n'

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH virt-v2v] v2v: Allow temporary directory to be set on a global basis.

2020-06-17 Thread Tomáš Golembiovský
On Tue, 16 Jun 2020 22:06:58 +0100
"Richard W.M. Jones"  wrote:

> On Tue, Jun 16, 2020 at 04:34:15PM +0200, Tomáš Golembiovský wrote:
> > On Wed, 10 Jun 2020 11:31:33 +0100
> > "Richard W.M. Jones"  wrote:
> >   
> > > I finally got access to the container.  This is how it's configured:
> > > 
> > > * / => an overlay fs.
> > > 
> > > There is sufficient space here, and there are no "funny" restrictions,
> > > to be able to create the libguestfs appliance.  I proved this by
> > > setting TMPDIR to a temporary directory under / and running
> > > libguestfs-test-tool.
> > > 
> > > There appears to be quite a lot of free space here, so in fact the
> > > v2vovl files could easily be stored here too.  (They only store the
> > > conversion delta, not the full guest images.)  
> > 
> > The thing is that nobody can guarantee that there will be enough space.
> > The underlying filesystem (not the mountpoint) is shared between all the
> > containers running on the host. This is the reason why we have a PV on
> > /var/tmp -- to make sure we have guaranteed free space.  
> 
> This must surely be a problem for all containers?  Do containers
> behave semi-randomly when the host starts to run out of space?  All
> containers must have to assume that there's some space available in
> /tmp or /var/tmp surely.

My understanding is that the container should not require significant
amount of free space for runtime. If you need a permanent data storage
or larger amount of temporary storage you need to use a volume.

> 
> If we can guarantee that each container has 1 or 2 G of free space
> (doesn't seem unreasonable?) then virt-v2v should work fine and won't
> need any NFS mounts.

NFS is just one of the methods to provision a volume. There is also a
host-local provisioner that makes sure there is enough space on the
local storage -- which seems what you are suggesting -- but I do not
recall what were the arguments against using it.


> > > * /var/tmp => an NFS mount from a PVC
> > > 
> > > This is a large (2T) external NFS mount.  
> > 
> > I assume that is the free space in the underlying filesystem. From there
> > you should be guaranteed to "own" only 2GB (or something like that).
> >   
> > > I actually started two pods
> > > to see if they got the same NFS mount point, and they do.  Also I
> > > wrote files to /var/tmp in one pod and they were visible in the other.
> > > So this seems shared.  
> > 
> > You mean you run two pods based on some YAML template or you run two
> > pods from Kubevirt web UI?  
> 
> Two from a yaml template, however ...
> 
> > If you run the pods manually you may have
> > reused the existing PV/PVC. It is the web UI that should provision you
> > new scratch space for each pod. If that is not working then that is a
> > bug in Kubevirt.  
> 
> ... the PVC name was "v2v-conversion-temp" (and not some randomly
> generated name) suggesting that either the user must enter a new name
> every time or else they're all going to get the same NFS mount.
> Can you explain a bit more about how they get different mounts?

Oh, I see. That seems wrong then and is probably a bug in Kubevirt web
UI. Do you still have access to the testing environment?

> 
> > > Also it uses root squash (so root:root is
> > > mapped to 99:99).  
> > 
> > IMHO this is the main problem that I have been telling them about from
> > the start. Thanks for confirming it. Using root squash on the mount is
> > plain wrong.  
> 
> This is definitely the main problem, and is the direct cause of the
> error you were seeing.  I'm still not very confident that our locking
> will work reliably if two virt-v2v instances in different containers
> or pods see a shared /var/tmp.

They should not. If they do then it is a bug somewhere else and not in
virt-v2v.

Tomas

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> 


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH virt-v2v] v2v: Allow temporary directory to be set on a global basis.

2020-06-16 Thread Tomáš Golembiovský
> 64M 0   64M   0% /dev/shm
> tmpfs 
>3.9G  7.2M  3.9G   1% /etc/hostname
> tmpfs 
>3.9G  4.0K  3.9G   1% /data/input
> devtmpfs  
>3.9G 0  3.9G   0% /dev/kvm
> /dev/mapper/coreos-luks-root-nocrypt  
> 40G   17G   24G  41% /etc/hosts
> [nfs-server]:/NFSv4_vol_cnv/ibragins-2-3.cnv-qe.rhcloud.com.pvs/pv9   2.0T  
> 945G 1002G  49% /var/tmp
> [nfs-server]:/NFSv4_vol_cnv/ibragins-2-3.cnv-qe.rhcloud.com.pvs/pv15  2.0T  
> 945G 1002G  49% /data/vm/disk1
> tmpfs 
>3.9G   24K  3.9G   1% 
> /run/secrets/kubernetes.io/serviceaccount
> 
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> 


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH virt-v2v] v2v: Allow temporary directory to be set on a global basis.

2020-04-09 Thread Tomáš Golembiovský
On Tue, Apr 07, 2020 at 04:31:57PM +0200, Pino Toscano wrote:
> On Tuesday, 7 April 2020 14:59:11 CEST Tomáš Golembiovský wrote:
> > On Tue, Apr 07, 2020 at 02:33:20PM +0200, Pino Toscano wrote:
> > > On Tuesday, 7 April 2020 14:18:47 CEST Richard W.M. Jones wrote:
> > > > On Tue, Apr 07, 2020 at 01:25:02PM +0200, Pino Toscano wrote:
> > > > > The important thing is still that that you need to have space for the
> > > > > temporary files somewhere: be it /var/tmp, /mnt/scratch, whatever.
> > > > > Because of this, and the fact that usually containers are created
> > > > > fresh, the cache of the supermin appliance starts to make little 
> > > > > sense,
> > > > > and then a very simple solution is to point libguestfs to that extra
> > > > > space:
> > > > > 
> > > > >   $ dir=$(mktemp --tmpdir -d 
> > > > > /path/to/big/temporary/space/libguestfs.XX)
> > > > >   $ export LIBGUESTGS_CACHEDIR=$dir
> > > > >   $ export TMPDIR=$dir  # optionally
> > > > >   $ libguestfs-test-tool
> > > > >   [etc]
> > > > >   $ rm -rf $dir
> > > > > 
> > > > > Easy to use, already doable, solves all the issues.
> > > > 
> > > > So AIUI there are a few problems with this (although I'm still
> > > > investigating and trying to make a local reproducer):
> > > > 
> > > >  - The external large space may be on NFS, with the usual problems
> > > >there like root_squash, no SELinux labels, slowness.  This means
> > > >it's not suitable for the appliance, but might nevertheless be
> > > >suitable for overlay files.
> > > 
> > > If that is the only big storage space attached to a container, I do
> > > not see any alternative than use it, with all the caveats associated.
> > 
> > I have to aggree with this. You cannot avoid situations where the
> > appliance is on a network drive. If there are any inherent risks the
> > best you can do is let user know about those (documentation?).
> > 
> > > 
> > > Also, if we take as possible scenario the situation where /var/tmp is
> > > not that big, then we need to consider that may not be big enough to
> > > even store the cached supermin appliance (which is more than
> > > 300/350MB).
> > > 
> > > >  - The external large space may be shared with other containers, and
> > > >I'm not convinced that our locking in supermin will be safe if
> > > >multiple parallel instances start up at the same time.  We
> > > >certainly never tested it, and don't currently advise it.
> > > 
> > > That's why my suggestion above creates a specific temporary directory
> > > for each container: even with a shared /var/tmp, there will not be any
> > > cache stepping up on each other toes. This is something that this
> > > separate cachedir for virt-v2v does not solve at all.
> > 
> > Currently we don't share the temporary volume between instances in
> > Kubevirt, but the assumption that this can happen is valid and should be
> > considered.
> > 
> > > 
> > > > > This whole problem started from a QE report on leftover files after
> > > > > failed migrations: bz#1820282.
> > > > 
> > > > (I should note also there are two bugs which I personally think we can
> > > > solve with the same fix, but they are completely different bugs.)
> > > 
> > > I still do not understand how these changes have anything to do with
> > > bug 1814611, which in an offline discussion we found out that has
> > > mostly two causes:
> > > - the way the NFS storage is mounted over the /var/tmp in the
> > >   container, so what you create as root is not really with the UID/GID
> > >   expected
> > > - the fixed appliance in the container was not actually used, and thus
> > >   a rebuilt of the the supermin appliance was attempted, failing due
> > >   to the first issue
> > 
> > I am still not convinced this is the case. Based on the logs I shared in
> > private email I still believe that the fixed appliance was used
> > properly. You assumed that the appliance is not used because the cache
> > directory is being created, but as I also pointed out the cache
> > directory created in all situations because qemu temporary files are
> > stored there [1][2].
> 
> This may be the case, i.e. someth

Re: [Libguestfs] [PATCH virt-v2v] v2v: Allow temporary directory to be set on a global basis.

2020-04-07 Thread Tomáš Golembiovský
On Tue, Apr 07, 2020 at 02:33:20PM +0200, Pino Toscano wrote:
> On Tuesday, 7 April 2020 14:18:47 CEST Richard W.M. Jones wrote:
> > On Tue, Apr 07, 2020 at 01:25:02PM +0200, Pino Toscano wrote:
> > > The important thing is still that that you need to have space for the
> > > temporary files somewhere: be it /var/tmp, /mnt/scratch, whatever.
> > > Because of this, and the fact that usually containers are created
> > > fresh, the cache of the supermin appliance starts to make little sense,
> > > and then a very simple solution is to point libguestfs to that extra
> > > space:
> > > 
> > >   $ dir=$(mktemp --tmpdir -d 
> > > /path/to/big/temporary/space/libguestfs.XX)
> > >   $ export LIBGUESTGS_CACHEDIR=$dir
> > >   $ export TMPDIR=$dir  # optionally
> > >   $ libguestfs-test-tool
> > >   [etc]
> > >   $ rm -rf $dir
> > > 
> > > Easy to use, already doable, solves all the issues.
> > 
> > So AIUI there are a few problems with this (although I'm still
> > investigating and trying to make a local reproducer):
> > 
> >  - The external large space may be on NFS, with the usual problems
> >there like root_squash, no SELinux labels, slowness.  This means
> >it's not suitable for the appliance, but might nevertheless be
> >suitable for overlay files.
> 
> If that is the only big storage space attached to a container, I do
> not see any alternative than use it, with all the caveats associated.

I have to aggree with this. You cannot avoid situations where the
appliance is on a network drive. If there are any inherent risks the
best you can do is let user know about those (documentation?).

> 
> Also, if we take as possible scenario the situation where /var/tmp is
> not that big, then we need to consider that may not be big enough to
> even store the cached supermin appliance (which is more than
> 300/350MB).
> 
> >  - The external large space may be shared with other containers, and
> >I'm not convinced that our locking in supermin will be safe if
> >multiple parallel instances start up at the same time.  We
> >certainly never tested it, and don't currently advise it.
> 
> That's why my suggestion above creates a specific temporary directory
> for each container: even with a shared /var/tmp, there will not be any
> cache stepping up on each other toes. This is something that this
> separate cachedir for virt-v2v does not solve at all.

Currently we don't share the temporary volume between instances in
Kubevirt, but the assumption that this can happen is valid and should be
considered.

> 
> > > This whole problem started from a QE report on leftover files after
> > > failed migrations: bz#1820282.
> > 
> > (I should note also there are two bugs which I personally think we can
> > solve with the same fix, but they are completely different bugs.)
> 
> I still do not understand how these changes have anything to do with
> bug 1814611, which in an offline discussion we found out that has
> mostly two causes:
> - the way the NFS storage is mounted over the /var/tmp in the
>   container, so what you create as root is not really with the UID/GID
>   expected
> - the fixed appliance in the container was not actually used, and thus
>   a rebuilt of the the supermin appliance was attempted, failing due
>   to the first issue

I am still not convinced this is the case. Based on the logs I shared in
private email I still believe that the fixed appliance was used
properly. You assumed that the appliance is not used because the cache
directory is being created, but as I also pointed out the cache
directory created in all situations because qemu temporary files are
stored there [1][2].

> 
> Can you please explain me exactly how switching the location of
> temporary files (that were not mentioned in the bug at all) will fix
> this situation?

For the particular BZ 1814611, if we keep the fixed appliance we can
move the cache directory to something else than /var/tmp (just for the
qemu files). We would keep /var/tmp only for overlay files. But this is
more of a hack than intended usage I guess.

> 
> > > What this report doesn't say, however,
> > > is that beside the mentioned files that virt-v2v creates, there are
> > > also leftover files that libguestfs itself creates. These files are
> > > usually downloaded from the guest for the inspection, and generally not
> > > that big compared to e.g. the overlays that virt-v2v creates.
> > > Nonetheless, an abrupt exit of virt-v2v will leave those in place, and
> > > they will still slowly fill up the space on /var/tmp (or whatever is
> > > the location of $LIBGUESTFS_CACHEDIR).
> > 
> > I guess that small files being left around aren't really a problem.
> > The problem they have is large files being left around, and I can
> > understand why that would be an issue and not the small files.
> 
> Nobody is saying that the leftover files are not a problem. I'm saying
> that also the small files are a sort of problem -- sure, less critical,
> however still there 

Re: [Libguestfs] [PATCH v4] windows: delay installation of qemu-ga MSI

2020-03-10 Thread Tomáš Golembiovský
> > diff --git a/common b/common
> > index ea10827b..5371257c 16
> > --- a/common
> > +++ b/common
> > @@ -1 +1 @@
> > -Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90
> > +Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6
> 
> I think(?) this hunk was not intended?
> 

Yes, that's a mistake. Sorry for that.

Tomas


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v4] windows: delay installation of qemu-ga MSI

2020-03-05 Thread Tomáš Golembiovský
Instead of running firstboot script during early boot schedule a task
delayed for 2 minutes.

During the first boot, after virt-v2v conversion, Windows installs the
drivers injected by virt-v2v. When this installation is finished
Windows enforces some kind of internal reboot. This unfortunately
terminates any running firstboot scripts thus killing the installation
of qemu-ga MSI.

This is just a best-effort mitigation. It can still happen (e.g. with
slow disk drives) that the drivers are not yet installed when the
delayed installation starts. On the other hand we cannot delay it too
much otherwise we risk that the users logs in and will be doing some
work when the MSI installation starts. After MSI installation finishes
the VM needs to be rebooted which would be annoying if that would happen
under users hands. Although this is not a best fix (that may come later
as it is more complex, e.g. introducing waiting mechanism), the delay as
it is defined works in most cases. And it dramaticaly improves the
situations -- originaly I experienced more than 90% failure rate.

Signed-off-by: Tomáš Golembiovský 
---
 common |  2 +-
 v2v/convert_windows.ml | 17 +++--
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/common b/common
index ea10827b..5371257c 16
--- a/common
+++ b/common
@@ -1 +1 @@
-Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90
+Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6
diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 0fda1d4e..9b90f611 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -428,16 +428,13 @@ popd
  and configure_qemu_ga files =
List.iter (
  fun msi_path ->
-   let fb_script = "\
-echo Installing qemu-ga from " ^ msi_path ^ "
-\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
-set elvl=!errorlevel!
-echo Done installing qemu-ga error_level=!elvl!
-if !elvl! == 0 (
-  echo Restarting Windows...
-  shutdown /r /f /c \"rebooted by firstboot script\"
-)
-" in
+   let fb_script = sprintf "\
+echo Removing any previously scheduled qemu-ga installation
+schtasks.exe /Delete /TN Firstboot-qemu-ga /F
+echo Scheduling delayed installation of qemu-ga from %s
+powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe 
/Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\%s /forcerestart /qn /l+*vx 
C:\\%s.log\\\"\"
+  "
+  msi_path msi_path msi_path in
   Firstboot.add_firstboot_script g inspect.i_root
 ("install " ^ msi_path) fb_script;
 ) files
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v3] windows: delay installation of qemu-ga MSI

2020-03-05 Thread Tomáš Golembiovský
On Thu, Mar 05, 2020 at 08:49:04AM +, Richard W.M. Jones wrote:
> On Tue, Mar 03, 2020 at 03:45:49PM +0100, Tomáš Golembiovský wrote:
> > Instead of running firstboot script during early boot schedule a task
> > delayed for 2 minutes.
> > 
> > During the first boot, after virt-v2v conversion, Windows installs the
> > drivers injected by virt-v2v. When this installation is finished
> > Windows enforces some kind of internal reboot. This unfortunately
> > terminates any running firstboot scripts thus killing the installation
> > of qemu-ga MSI.
> > 
> > This is just a best-effort mitigation. It can still happen (e.g. with
> > slow disk drives) that the drivers are not yet installed when the
> > delayed installation starts. On the other hand we cannot delay it too
> > much otherwise we risk that the users logs in and will be doing some
> > work when the MSI installation starts. After MSI installation finishes
> > the VM needs to be rebooted which would be annoying if that would happen
> > under users hands. Although this is not a best fix (that may come later
> > as it is more complex, e.g. introducing waiting mechanism), the delay as
> > it is defined works in most cases. And it dramaticaly improves the
> > situations -- originaly I experienced more than 90% failure rate.
> > 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  common |  2 +-
> >  v2v/convert_windows.ml | 12 
> >  2 files changed, 5 insertions(+), 9 deletions(-)
> > 
> > diff --git a/common b/common
> > index ea10827b..5371257c 16
> > --- a/common
> > +++ b/common
> > @@ -1 +1 @@
> > -Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90
> > +Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6
> > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
> > index 0fda1d4e..bed5989a 100644
> > --- a/v2v/convert_windows.ml
> > +++ b/v2v/convert_windows.ml
> > @@ -429,14 +429,10 @@ popd
> > List.iter (
> >   fun msi_path ->
> > let fb_script = "\
> > -echo Installing qemu-ga from " ^ msi_path ^ "
> > -\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
> > -set elvl=!errorlevel!
> > -echo Done installing qemu-ga error_level=!elvl!
> > -if !elvl! == 0 (
> > -  echo Restarting Windows...
> > -  shutdown /r /f /c \"rebooted by firstboot script\"
> > -)
> > +echo Removing any previously scheduled qemu-ga installation
> > +schtasks.exe /Delete /TN Firstboot-qemu-ga /F
> > +echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ "
> > +powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe 
> > /Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
> > SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn 
> > /l+*vx C:\\" ^ msi_path ^ ".log\\\"\"
> >  " in
> >Firstboot.add_firstboot_script g inspect.i_root
> >  ("install " ^ msi_path) fb_script;
> 
> It could be easier to follow if you use sprintf here, something like:
> 
> let fb_script = sprintf "\
> echo Removing any previously scheduled qemu-ga installation
> schtasks.exe /Delete /TN Firstboot-qemu-ga /F
> echo Scheduling delayed installation of qemu-ga from %s
> powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe 
> /Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
> SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\%s /forcerestart /qn /l+*vx 
> C:\\%s.log\\\"\"
>   msi_path msi_path msi_path in

Ok, I can change that.

> 
> The other possible problem is this seems to install a firstboot script
> for every element of the list qemu_ga_files.  How long is this list?

At the moment it is just one. Until something changes in virtio-win ISO
or in our internal logic (like in virtio_iso_path_matches_qemu_ga()) it
will always be one.

> 
> Do filenames on this list need some kind of quoting?  The filenames
> don't, but they seem to contain a path that comes from the virtio-win
> ISO.

Those are really just file names without path. See 
https://github.com/libguestfs/virt-v2v/blob/master/v2v/windows_virtio.ml#L339

Tomas

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> 

-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 1/1] windows: delay installation of qemu-ga MSI

2020-03-03 Thread Tomáš Golembiovský
On Tue, Mar 03, 2020 at 01:37:24PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 03, 2020 at 02:27:46PM +0100, Tomáš Golembiovský wrote:
> > On Mon, Mar 02, 2020 at 11:35:29AM +, Daniel P. Berrangé wrote:
> > > On Mon, Mar 02, 2020 at 12:26:00PM +0100, Tomáš Golembiovský wrote:
> > > > Instead of running firstboot script during early boot schedule a task
> > > > delayed for 1-2 minute.
> > > 
> > > IIUC, you picked 119 seconds, so effectively 2 minutes. IOW, s/1-2/2/
> > > 
> > 
> > Well, the time is rounded down to minutes. It cannot be scheduled with
> > precision in seconds. So when scheduling in 00:00:00 it will be set to
> > 00:01:00. But now that I look at it it should be 120 and not 119. That
> > way it will always be 2 minutes. I am not sure what math error did I do
> > when I wrote it originaly.
> > 
> > 
> > > > During the first boot, after virt-v2v conversion, Windows installs the
> > > > drivers injected by virit-v2v. When this installation is finished
> > > 
> > > s/virit/virt/
> > > 
> > > > Windows enforces some kind of internal reboot. This unfortunately
> > > > terminates any running firstboot scritps thus killing the installation
> > > 
> > > s/scritpts/scripts/
> > > 
> > 
> > Thanks for spotting the typos.
> > 
> > > > of qemu-ga MSI.
> > > 
> > > IIUC, the expectation is that the Windows installation of the
> > > drivers will be completed *before* this 2 minute delay occurs.
> > > Windows will then reboot, and the delayed GA job will be run
> > > after this reboot ?
> > 
> > Correct.
> > 
> > > 
> > > The key question is how confident are we that the 2 minute
> > > delay is sufficient ?  Is there chance of still hitting the
> > > problem if doing v2v on slow (ie HDD, not SSD) storage
> > > for example ?
> > 
> > This is a best effort. What you're describing can happen and the user
> > will be screwed. But bear in mind that as it is now it is virtualy never
> > working. You cannot set the delay too long either. If the user starts
> > doing something once the VM boots you don't want to restart the VM (once
> > MSI is installed) under the user's hands.
> > 
> > I am currently investigating how could we use PowerShell features to
> > introduce some waiting mechanism (e.g. for the serial device) to handle
> > this better. But that will take some time.
> 
> Ok, understood. Can you expand the commit message with some of this
> info to make it clear this isn't a real fix, it is just a mitigation
> with caveats about possible failure in slow VMs.

Updated in v3. Let me know if you think I omitted something.

Tomas

> 
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
> 

-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v3] windows: delay installation of qemu-ga MSI

2020-03-03 Thread Tomáš Golembiovský
Instead of running firstboot script during early boot schedule a task
delayed for 2 minutes.

During the first boot, after virt-v2v conversion, Windows installs the
drivers injected by virt-v2v. When this installation is finished
Windows enforces some kind of internal reboot. This unfortunately
terminates any running firstboot scripts thus killing the installation
of qemu-ga MSI.

This is just a best-effort mitigation. It can still happen (e.g. with
slow disk drives) that the drivers are not yet installed when the
delayed installation starts. On the other hand we cannot delay it too
much otherwise we risk that the users logs in and will be doing some
work when the MSI installation starts. After MSI installation finishes
the VM needs to be rebooted which would be annoying if that would happen
under users hands. Although this is not a best fix (that may come later
as it is more complex, e.g. introducing waiting mechanism), the delay as
it is defined works in most cases. And it dramaticaly improves the
situations -- originaly I experienced more than 90% failure rate.

Signed-off-by: Tomáš Golembiovský 
---
 common |  2 +-
 v2v/convert_windows.ml | 12 
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/common b/common
index ea10827b..5371257c 16
--- a/common
+++ b/common
@@ -1 +1 @@
-Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90
+Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6
diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 0fda1d4e..bed5989a 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -429,14 +429,10 @@ popd
List.iter (
  fun msi_path ->
let fb_script = "\
-echo Installing qemu-ga from " ^ msi_path ^ "
-\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
-set elvl=!errorlevel!
-echo Done installing qemu-ga error_level=!elvl!
-if !elvl! == 0 (
-  echo Restarting Windows...
-  shutdown /r /f /c \"rebooted by firstboot script\"
-)
+echo Removing any previously scheduled qemu-ga installation
+schtasks.exe /Delete /TN Firstboot-qemu-ga /F
+echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ "
+powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe 
/Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn 
/l+*vx C:\\" ^ msi_path ^ ".log\\\"\"
 " in
   Firstboot.add_firstboot_script g inspect.i_root
 ("install " ^ msi_path) fb_script;
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2] windows: delay installation of qemu-ga MSI

2020-03-03 Thread Tomáš Golembiovský
Instead of running firstboot script during early boot schedule a task
delayed for 2 minutes.

During the first boot, after virt-v2v conversion, Windows installs the
drivers injected by virt-v2v. When this installation is finished
Windows enforces some kind of internal reboot. This unfortunately
terminates any running firstboot scripts thus killing the installation
of qemu-ga MSI.

Signed-off-by: Tomáš Golembiovský 
---
 common |  2 +-
 v2v/convert_windows.ml | 12 
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/common b/common
index ea10827b..5371257c 16
--- a/common
+++ b/common
@@ -1 +1 @@
-Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90
+Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6
diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 0fda1d4e..bed5989a 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -429,14 +429,10 @@ popd
List.iter (
  fun msi_path ->
let fb_script = "\
-echo Installing qemu-ga from " ^ msi_path ^ "
-\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
-set elvl=!errorlevel!
-echo Done installing qemu-ga error_level=!elvl!
-if !elvl! == 0 (
-  echo Restarting Windows...
-  shutdown /r /f /c \"rebooted by firstboot script\"
-)
+echo Removing any previously scheduled qemu-ga installation
+schtasks.exe /Delete /TN Firstboot-qemu-ga /F
+echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ "
+powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe 
/Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn 
/l+*vx C:\\" ^ msi_path ^ ".log\\\"\"
 " in
   Firstboot.add_firstboot_script g inspect.i_root
 ("install " ^ msi_path) fb_script;
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 1/1] windows: delay installation of qemu-ga MSI

2020-03-03 Thread Tomáš Golembiovský
On Mon, Mar 02, 2020 at 11:35:29AM +, Daniel P. Berrangé wrote:
> On Mon, Mar 02, 2020 at 12:26:00PM +0100, Tomáš Golembiovský wrote:
> > Instead of running firstboot script during early boot schedule a task
> > delayed for 1-2 minute.
> 
> IIUC, you picked 119 seconds, so effectively 2 minutes. IOW, s/1-2/2/
> 

Well, the time is rounded down to minutes. It cannot be scheduled with
precision in seconds. So when scheduling in 00:00:00 it will be set to
00:01:00. But now that I look at it it should be 120 and not 119. That
way it will always be 2 minutes. I am not sure what math error did I do
when I wrote it originaly.


> > During the first boot, after virt-v2v conversion, Windows installs the
> > drivers injected by virit-v2v. When this installation is finished
> 
> s/virit/virt/
> 
> > Windows enforces some kind of internal reboot. This unfortunately
> > terminates any running firstboot scritps thus killing the installation
> 
> s/scritpts/scripts/
> 

Thanks for spotting the typos.

> > of qemu-ga MSI.
> 
> IIUC, the expectation is that the Windows installation of the
> drivers will be completed *before* this 2 minute delay occurs.
> Windows will then reboot, and the delayed GA job will be run
> after this reboot ?

Correct.

> 
> The key question is how confident are we that the 2 minute
> delay is sufficient ?  Is there chance of still hitting the
> problem if doing v2v on slow (ie HDD, not SSD) storage
> for example ?

This is a best effort. What you're describing can happen and the user
will be screwed. But bear in mind that as it is now it is virtualy never
working. You cannot set the delay too long either. If the user starts
doing something once the VM boots you don't want to restart the VM (once
MSI is installed) under the user's hands.

I am currently investigating how could we use PowerShell features to
introduce some waiting mechanism (e.g. for the serial device) to handle
this better. But that will take some time.

Tomas

> 
> > 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/convert_windows.ml | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> > 
> > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
> > index 0fda1d4e..0a146006 100644
> > --- a/v2v/convert_windows.ml
> > +++ b/v2v/convert_windows.ml
> > @@ -429,14 +429,10 @@ popd
> > List.iter (
> >   fun msi_path ->
> > let fb_script = "\
> > -echo Installing qemu-ga from " ^ msi_path ^ "
> > -\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
> > -set elvl=!errorlevel!
> > -echo Done installing qemu-ga error_level=!elvl!
> > -if !elvl! == 0 (
> > -  echo Restarting Windows...
> > -  shutdown /r /f /c \"rebooted by firstboot script\"
> > -)
> > +echo Removing any previously scheduled qemu-ga installation
> > +schtasks.exe /Delete /TN Firstboot-qemu-ga /F
> > +echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ "
> > +powershell.exe -command \"$d = (get-date).AddSeconds(119); schtasks.exe 
> > /Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
> > SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn 
> > /l+*vx C:\\" ^ msi_path ^ ".log\\\"\"
> >  " in
> >Firstboot.add_firstboot_script g inspect.i_root
> >  ("install " ^ msi_path) fb_script;
> > -- 
> > 2.25.0
> > 
> > 
> > ___
> > Libguestfs mailing list
> > Libguestfs@redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
> 

-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 1/1] windows: delay installation of qemu-ga MSI

2020-03-02 Thread Tomáš Golembiovský
Instead of running firstboot script during early boot schedule a task
delayed for 1-2 minute.

During the first boot, after virt-v2v conversion, Windows installs the
drivers injected by virit-v2v. When this installation is finished
Windows enforces some kind of internal reboot. This unfortunately
terminates any running firstboot scritps thus killing the installation
of qemu-ga MSI.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_windows.ml | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 0fda1d4e..0a146006 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -429,14 +429,10 @@ popd
List.iter (
  fun msi_path ->
let fb_script = "\
-echo Installing qemu-ga from " ^ msi_path ^ "
-\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
-set elvl=!errorlevel!
-echo Done installing qemu-ga error_level=!elvl!
-if !elvl! == 0 (
-  echo Restarting Windows...
-  shutdown /r /f /c \"rebooted by firstboot script\"
-)
+echo Removing any previously scheduled qemu-ga installation
+schtasks.exe /Delete /TN Firstboot-qemu-ga /F
+echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ "
+powershell.exe -command \"$d = (get-date).AddSeconds(119); schtasks.exe 
/Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn 
/l+*vx C:\\" ^ msi_path ^ ".log\\\"\"
 " in
   Firstboot.add_firstboot_script g inspect.i_root
 ("install " ^ msi_path) fb_script;
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 0/1] Delay installation of QEMU-GA

2020-03-02 Thread Tomáš Golembiovský
This is a replacement for previously posted patch "Delay firstboot scripts to
some later time":

https://www.redhat.com/archives/libguestfs/2019-November/msg00134.html

Instead of delaying all the firstboot scripts we just delay the QEMU-GA
installation that we know is problematic. I will possibly send a similar patch
for RHEV-APT installation later.

Tomáš Golembiovský (1):
  windows: delay installation of qemu-ga MSI

 v2v/convert_windows.ml | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 2/2] firstboot: schedule firstboot as delayed task

2020-02-13 Thread Tomáš Golembiovský
> > I have really no clue about this.
> > 
> > What is "~dpnx0"?  
> 
> I wanted to documented that in a comment at first. But then I decided
> against that as it seemed that as it seemed such patterns are used in
> multiple places in the code (ergo everyone knows).
> 
> Looking now I see two occurrence in convert_windows.ml and one in
> firstboot.ml. I guess picking one of those for the comment should be
> enough.
> 

For completeness, "~dpnx0" expands into the name of the running script
(0) with full path (p), including drive letter (d) and filename (n) with
extension (x).

Tomas

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs



Re: [Libguestfs] [PATCH 2/2] firstboot: schedule firstboot as delayed task

2020-02-13 Thread Tomáš Golembiovský
On Tue, 11 Feb 2020 14:36:24 +
"Richard W.M. Jones"  wrote:

> On Thu, Nov 21, 2019 at 12:04:18PM +0100, Tomáš Golembiovský wrote:
> > Instead of running firstboot scripts during early boot schedule a task
> > delayed for 1-2 minute.
> > 
> > During the first boot, after virt-v2v conversion, Windows installs the
> > drivers injected by virit-v2v. When this installation is finished
> > Windows enforces some kind of internal reboot. This unfortunately
> > terminates any running firstboot scritps thus killing for example the
> > installation of qemu-ga MSI.
> > 
> > Hopefully delaying the installtion to some later time can also fix
> > problem we sometimes saw on Windows 2012R2 when installing RHEV-APT,
> > where the installer terminated immediately with the error:
> > 
> >   Failed to connect to server. Error: 0x8007045B
> > 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  mlcustomize/firstboot.ml | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mlcustomize/firstboot.ml b/mlcustomize/firstboot.ml
> > index c3ebfd9..b4ca181 100644
> > --- a/mlcustomize/firstboot.ml
> > +++ b/mlcustomize/firstboot.ml
> > @@ -286,10 +286,18 @@ set log=%%firstboot%%\\log.txt
> >  set scripts=%%firstboot%%\\scripts
> >  set scripts_done=%%firstboot%%\\scripts-done
> >  
> > -call :main >> \"%%log%%\" 2>&1
> > +call :main %%1 >> \"%%log%%\" 2>&1
> >  exit /b
> >  
> >  :main
> > +
> > +if not '%%1' == 'real' (
> > +REM schedule delayed task
> > +schtasks.exe /Delete /TN Firstboot /F
> > +powershell.exe -command \"$d = (get-date).AddSeconds(119); 
> > schtasks.exe /Create /SC ONCE /ST $d.ToString('HH:mm') /SD 
> > $d.ToString('MM/dd/') /RU SYSTEM /TN Firstboot /TR \\\"%%~dpnx0 
> > real\\\"\"
> > +exit /b
> > +)
> > +
> >  echo starting firstboot service  
> 
> I have really no clue about this.
> 
> What is "~dpnx0"?

I wanted to documented that in a comment at first. But then I decided
against that as it seemed that as it seemed such patterns are used in
multiple places in the code (ergo everyone knows).

Looking now I see two occurrence in convert_windows.ml and one in
firstboot.ml. I guess picking one of those for the comment should be
enough.


> 
> I wwill say that in general we do need a way that we can order
> firstboot scripts so that some run before others.  At the moment the
> Windows static IP script sometimes runs before the network device is
> created (see https://bugzilla.redhat.com/1788823).  I guess we could
> hack that by making the sleep time above settable when registering a
> firstboot script, but what we really need is some kind of dependency
> system.  I have no idea if Windows has a mechanism to do this already.

Such ordering or dependency mechanism would be nice, but I guess that's
beyond what command line tools provide. Maybe we could script that to
some degree if we turn the main firstboot script completely into
PowerShell. But that would mean opening a can of worms.

Tomas

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> 


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 0/2] Fixes and tweak to the installation of qemu-ga MSI

2020-02-05 Thread Tomáš Golembiovský
This, together with the changes to common repo are fixes to the installation
qemu-ga MSI.

There is still an issue that I did not figure yet how to fix. On Windows 10 it
fails to register the QEMU-GA service.

Tomáš Golembiovský (2):
  windows: fix detection of qemu-ga installer on RHV
  windows: small tweaks of qemu-ga firstboot script

 v2v/convert_windows.ml | 8 +++-
 v2v/windows_virtio.ml  | 5 ++---
 2 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 2/2] windows: small tweaks of qemu-ga firstboot script

2020-02-05 Thread Tomáš Golembiovský
- match log file with script name
- restart manually only after successfull install, this also helps
  debugging because we can log the installer return code

Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_windows.ml | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 5b7a5bfe..0fda1d4e 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -430,7 +430,13 @@ popd
  fun msi_path ->
let fb_script = "\
 echo Installing qemu-ga from " ^ msi_path ^ "
-\"\\" ^ msi_path ^ "\" /qn /forcerestart /l+*vx \"%cd%\\qemu-ga.log\"
+\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
+set elvl=!errorlevel!
+echo Done installing qemu-ga error_level=!elvl!
+if !elvl! == 0 (
+  echo Restarting Windows...
+  shutdown /r /f /c \"rebooted by firstboot script\"
+)
 " in
   Firstboot.add_firstboot_script g inspect.i_root
 ("install " ^ msi_path) fb_script;
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 1/2] windows: fix detection of qemu-ga installer on RHV

2020-02-05 Thread Tomáš Golembiovský
The detection was incorrectly matching only 32-bit installer on all
architectures.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 5ec7664b..f8863a6a 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -450,14 +450,13 @@ and virtio_iso_path_matches_qemu_ga path inspect =
* elements.
*)
   let lc_name = String.lowercase_ascii (Filename.basename path) in
-  lc_name = "rhev-qga.msi" ||
   match arch, lc_name with
   | ("i386", "qemu-ga-x86.msi")
   | ("i386", "qemu-ga-i386.msi")
-  | ("i386", "RHEV-QGA.msi")
+  | ("i386", "rhev-qga.msi")
   | ("x86_64", "qemu-ga-x64.msi")
   | ("x86_64", "qemu-ga-x86_64.msi")
-  | ("x86_64", "RHEV-QGA64.msi") -> true
+  | ("x86_64", "rhev-qga64.msi") -> true
   | _ -> false
 
 (* The following function is only exported for unit tests. *)
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 0/2] Fixes and tweak to the installation of qemu-ga MSI

2020-02-05 Thread Tomáš Golembiovský
On Mon, Jan 27, 2020 at 04:59:55PM +0100, Pino Toscano wrote:
> On Thursday, 21 November 2019 12:11:00 CET Tomáš Golembiovský wrote:
> > This, together with the changes to common repo are fixes to the installation
> > qemu-ga MSI.
> 
> I pushed patch #1 because it is OK for me.
> 
> I did not push patch #2 because I do not have experience with
> powershell, so I cannot review it ATM.
> 
> > There is still an issue that I did not figure yet how to fix. On Windows 10 
> > it
> > fails to register the QEMU-GA service.
> 
> Can you please explain which kind of issues did you notice?

The main problem is this error that I get quite often is that qemu-ga
fails to register the VSS service. On the same guest it sometimes works
and sometimes it fails. And it happens only when installing in first
boot, installing manually always works.

>From installer log:

MSI (s) (C4:00) [13:59:58:205]: Executing op: 
ServiceInstall(Name=QEMU-GA,DisplayName=QEMU Guest Agent,ImagePath="C:\Program 
Files\Qemu-ga\qemu-ga.exe" -d 
--retry-path,ServiceType=16,StartType=2,ErrorControl=0,,Dependencies=[~],,StartName=LocalSystem,Password=**,Description=QEMU
 Guest Agent,,)
MSI (s) (C4:00) [13:59:58:205]: Executing op: ActionStart(Name=RegisterCom,,)
MSI (s) (C4:00) [13:59:58:221]: Executing op: 
CustomActionSchedule(Action=RegisterCom,ActionType=3122,Source=cmd.exe,Target=/c
 "C:\Program Files\Qemu-ga\qemu-ga.exe" -s vss-install,)
MSI (s) (C4:00) [14:00:00:299]: Note: 1: 1722 2: RegisterCom 3: cmd.exe 4: /c 
"C:\Program Files\Qemu-ga\qemu-ga.exe" -s vss-install 
MSI (s) (C4:00) [14:00:00:299]: Note: 1: 2262 2: Error 3: -2147287038 
CustomAction RegisterCom returned actual error code 1 (note this may not be 
100% accurate if translation happened inside sandbox)
MSI (s) (C4:00) [14:00:00:299]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (C4:00) [14:00:00:299]: Product: QEMU guest agent -- Error 1722. There 
is a problem with this Windows Installer package. A program run as part of the 
setup did not finish as expected. Contact your support personnel or package 
vendor.  Action RegisterCom, location: cmd.exe, command: /c "C:\Program 
Files\Qemu-ga\qemu-ga.exe" -s vss-install 

Error 1722. There is a problem with this Windows Installer package. A program 
run as part of the setup did not finish as expected. Contact your support 
personnel or package vendor.  Action RegisterCom, location: cmd.exe, command: 
/c "C:\Program Files\Qemu-ga\qemu-ga.exe" -s vss-install 


The cryptic error[1] code -2147287038 seems to be:

STG_E_INVALIDFUNCTION 0x80030001Unable to perform requested operation.

I haven't figured out yet why is it happening. 

Tomas

[1] https://docs.microsoft.com/en-us/windows/win32/com/com-error-codes-3


> 
> Thanks,
> -- 
> Pino Toscano



-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 1/2] windows: fix detection of qemu-ga installer on RHV

2020-02-05 Thread Tomáš Golembiovský
On Mon, Jan 27, 2020 at 05:01:57PM +0100, Pino Toscano wrote:
> On Thursday, 21 November 2019 12:11:01 CET Tomáš Golembiovský wrote:
> > The detection was incorrectly matching only 32-bit installer on all
> > architectures.
> > 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/windows_virtio.ml | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
> > index 5ec7664b..f47d28e0 100644
> > --- a/v2v/windows_virtio.ml
> > +++ b/v2v/windows_virtio.ml
> > @@ -450,14 +450,13 @@ and virtio_iso_path_matches_qemu_ga path inspect =
> > * elements.
> > *)
> >let lc_name = String.lowercase_ascii (Filename.basename path) in
> > -  lc_name = "rhev-qga.msi" ||
> >match arch, lc_name with
> >| ("i386", "qemu-ga-x86.msi")
> >| ("i386", "qemu-ga-i386.msi")
> > -  | ("i386", "RHEV-QGA.msi")
> > +  | ("i386", "rhev-qga.msi")
> >| ("x86_64", "qemu-ga-x64.msi")
> >| ("x86_64", "qemu-ga-x86_64.msi")
> > -  | ("x86_64", "RHEV-QGA64.msi") -> true
> > +  | ("x86_64", "rhev-qga64.msi")
> >| _ -> false
> 
> Actually, after another pre-push re-read, this function
> (virtio_iso_path_matches_qemu_ga) will always return false now!

Oh! How did that happen?! :)

Thanks for noticing, Pino.

Tomas

> 
> -- 
> Pino Toscano



-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 3/3] docs: don't perform lookup on absolute paths

2020-01-27 Thread Tomáš Golembiovský
On Mon, Jan 27, 2020 at 01:46:03PM +0100, Pino Toscano wrote:
> On Monday, 27 January 2020 12:37:38 CET Tomáš Golembiovský wrote:
> > On Mon, Jan 27, 2020 at 12:17:42PM +0100, Pino Toscano wrote:
> > > On Monday, 27 January 2020 10:39:34 CET Tomáš Golembiovský wrote:
> > > > Signed-off-by: Tomáš Golembiovský 
> > > > ---
> > > >  podwrapper.pl.in | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/podwrapper.pl.in b/podwrapper.pl.in
> > > > index f12a173f..1e4aa149 100755
> > > > --- a/podwrapper.pl.in
> > > > +++ b/podwrapper.pl.in
> > > > @@ -689,6 +689,8 @@ sub find_file
> > > >  my $use_path = shift;
> > > >  local $_;
> > > >  
> > > > +return $input if File::Spec->file_name_is_absolute($input) and -f 
> > > > $input;
> > > 
> > > Do you really need to use file_name_is_absolute? -f seems to work fine
> > > also with absolute paths. In case the path is relative, -f will be fine
> > > too, as...
> > 
> > It's all about skipping the code below. The '.' will turn your nice
> > absolute path '/foo/bar' into relative path './foo/bar' and the lookup
> > will fail.
> 
> Oh sorry, most probably I did not explain properly what I meant.
> 
> Since -f works on both absolute and relative paths, my suggestion is
> to change your line into a simpler:
> 
>   return $input if $input;
> 
> and most probably removing '.' from the search loop below.

Now I see what you mean. Yeah, that makes sense too.

Tomas

> 
> -- 
> Pino Toscano



> ___
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 3/3] docs: don't perform lookup on absolute paths

2020-01-27 Thread Tomáš Golembiovský
On Mon, Jan 27, 2020 at 12:17:42PM +0100, Pino Toscano wrote:
> On Monday, 27 January 2020 10:39:34 CET Tomáš Golembiovský wrote:
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  podwrapper.pl.in | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/podwrapper.pl.in b/podwrapper.pl.in
> > index f12a173f..1e4aa149 100755
> > --- a/podwrapper.pl.in
> > +++ b/podwrapper.pl.in
> > @@ -689,6 +689,8 @@ sub find_file
> >  my $use_path = shift;
> >  local $_;
> >  
> > +return $input if File::Spec->file_name_is_absolute($input) and -f 
> > $input;
> 
> Do you really need to use file_name_is_absolute? -f seems to work fine
> also with absolute paths. In case the path is relative, -f will be fine
> too, as...

It's all about skipping the code below. The '.' will turn your nice
absolute path '/foo/bar' into relative path './foo/bar' and the lookup
will fail.

Instead of letting it fall through maybe something like this would be
more expressive:

if File::Spec->file_name_is_absolute($input) {
return $input if -f $input;
die "$progname: $input: cannot find input file"
}

> 
> >  my @search_path = (".");
> >  push (@search_path, @paths) if $use_path;
> >  foreach (@search_path) {
> 
> ... the first search path is always '.'.
> 
> -- 
> Pino Toscano



> ___
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 1/3] build: perform gnulib check from source directory

2020-01-27 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 cfg.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cfg.mk b/cfg.mk
index a303ee72..4bd2d006 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -132,6 +132,7 @@ ifeq (0,$(MAKELEVEL))
   # b653eda3ac4864de205419d9f41eec267cb89eeb
   _submodule_hash = sed 's/^[ +-]//;s/ .*//'
   _update_required := $(shell  \
+  cd $(top_srcdir);
\
   actual=$$(git submodule status | grep gnulib | $(_submodule_hash));  
\
   stamp="$$($(_submodule_hash) $(_curr_status) 2>/dev/null)";  \
   test "$$stamp" = "$$actual"; echo $$?)
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 3/3] docs: don't perform lookup on absolute paths

2020-01-27 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 podwrapper.pl.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/podwrapper.pl.in b/podwrapper.pl.in
index f12a173f..1e4aa149 100755
--- a/podwrapper.pl.in
+++ b/podwrapper.pl.in
@@ -689,6 +689,8 @@ sub find_file
 my $use_path = shift;
 local $_;
 
+return $input if File::Spec->file_name_is_absolute($input) and -f $input;
+
 my @search_path = (".");
 push (@search_path, @paths) if $use_path;
 foreach (@search_path) {
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 0/3] Fixing out-of-tree builds

2020-01-27 Thread Tomáš Golembiovský
Building virt-v2v out-of-tree does not work and requires several small fixes
here and there.

Tomáš Golembiovský (3):
  build: perform gnulib check from source directory
  build: run ocaml-link.sh from build directory
  docs: don't perform lookup on absolute paths

 cfg.mk   |  1 +
 podwrapper.pl.in |  2 ++
 v2v/Makefile.am  | 16 
 3 files changed, 11 insertions(+), 8 deletions(-)

-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 2/3] build: run ocaml-link.sh from build directory

2020-01-27 Thread Tomáš Golembiovský
ocaml-link.sh is generated file. It means that for out-of-tree builds it
is located in a build directory which is different from source tree dir.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/Makefile.am | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/v2v/Makefile.am b/v2v/Makefile.am
index 64703c36..1c10d07b 100644
--- a/v2v/Makefile.am
+++ b/v2v/Makefile.am
@@ -248,9 +248,9 @@ OCAMLLINKFLAGS = \
mlv2v.$(MLARCHIVE) \
$(LINK_CUSTOM_OCAMLC_ONLY)
 
-virt_v2v_DEPENDENCIES = $(OBJECTS) $(top_srcdir)/ocaml-link.sh
+virt_v2v_DEPENDENCIES = $(OBJECTS) $(top_builddir)/ocaml-link.sh
 virt_v2v_LINK = \
-   $(top_srcdir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
+   $(top_builddir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
  $(OCAMLFIND) $(BEST) $(OCAMLFLAGS) $(OCAMLPACKAGES) $(OCAMLLINKFLAGS) 
\
  $(OBJECTS) -o $@
 
@@ -293,9 +293,9 @@ virt_v2v_copy_to_local_DEPENDENCIES = \
../bundled/libvirt-ocaml/mllibvirt.$(MLARCHIVE) \
../common/mlcustomize/mlcustomize.$(MLARCHIVE) \
../common/mlv2v/mlv2v.$(MLARCHIVE) \
-   $(top_srcdir)/ocaml-link.sh
+   $(top_builddir)/ocaml-link.sh
 virt_v2v_copy_to_local_LINK = \
-   $(top_srcdir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
+   $(top_builddir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
  $(OCAMLFIND) $(BEST) $(OCAMLFLAGS) $(OCAMLPACKAGES) $(OCAMLLINKFLAGS) 
\
  $(COPY_TO_LOCAL_OBJECTS) -o $@
 
@@ -367,9 +367,9 @@ v2v_unit_tests_DEPENDENCIES = \
../common/mltools/mltools.$(MLARCHIVE) \
../common/mlcustomize/mlcustomize.$(MLARCHIVE) \
../common/mlv2v/mlv2v.$(MLARCHIVE) \
-   $(top_srcdir)/ocaml-link.sh
+   $(top_builddir)/ocaml-link.sh
 v2v_unit_tests_LINK = \
-   $(top_srcdir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
+   $(top_builddir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
  $(OCAMLFIND) $(BEST) $(OCAMLFLAGS) \
  $(OCAMLPACKAGES) -package oUnit \
  $(OCAMLLINKFLAGS) \
@@ -378,9 +378,9 @@ v2v_unit_tests_LINK = \
 var_expander_tests_DEPENDENCIES = \
$(var_expander_tests_THEOBJECTS) \
../common/mlpcre/mlpcre.$(MLARCHIVE) \
-   $(top_srcdir)/ocaml-link.sh
+   $(top_builddir)/ocaml-link.sh
 var_expander_tests_LINK = \
-   $(top_srcdir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
+   $(top_builddir)/ocaml-link.sh -cclib '$(OCAMLCLIBS)' -- \
  $(OCAMLFIND) $(BEST) $(OCAMLFLAGS) \
  $(OCAMLPACKAGES) -package oUnit \
  $(OCAMLLINKFLAGS) \
-- 
2.25.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH] vCenter: pass user name to nbdkit curl plugin

2020-01-20 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/vCenter.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/v2v/vCenter.ml b/v2v/vCenter.ml
index 89c5579b..d9bf12c1 100644
--- a/v2v/vCenter.ml
+++ b/v2v/vCenter.ml
@@ -79,7 +79,7 @@ let rec map_source ?bandwidth ?password_file dcPath uri 
server path =
 
   let nbdkit =
 Nbdkit.create_curl ?bandwidth ?cookie:session_cookie ~password ~sslverify
-   https_url in
+   ?user:uri.uri_user https_url in
   let qemu_uri = Nbdkit.run nbdkit in
 
   (* Return the struct. *)
-- 
2.24.1


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH] nbdkit: fix condition in probe_filter

2020-01-20 Thread Tomáš Golembiovský
The tests assume probe_filter returns true if the filter is available
(and not the other way around).

Signed-off-by: Tomáš Golembiovský 
---
 v2v/nbdkit.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/v2v/nbdkit.ml b/v2v/nbdkit.ml
index 77d2a506..00122bec 100644
--- a/v2v/nbdkit.ml
+++ b/v2v/nbdkit.ml
@@ -142,7 +142,7 @@ let common_create ?bandwidth plugin_name plugin_args 
plugin_env =
 let cmd =
   sprintf "%s nbdkit --dump-plugin --filter=%s null >/dev/null"
   env_as_string filter_name in
-Sys.command cmd <> 0
+Sys.command cmd == 0
   in
 
   (* Adding the readahead filter is always a win for our access
-- 
2.24.1


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2] add versioned directory for guest agent on EL8

2020-01-16 Thread Tomáš Golembiovský
There was no source directory for EL8 guest agent (only EL6 and EL7).

RHBZ#1791802

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 5ec7664b..86bc8c0a 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -192,6 +192,7 @@ and install_linux_tools g inspect =
   (match inspect.i_major_version with
| 6 -> Some "el6"
| 7 -> Some "el7"
+   | 8 -> Some "el8"
| _ -> None)
 | "sles" | "suse-based" | "opensuse" -> Some "lp151"
 | _ -> None in
-- 
2.24.1


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH] add default (unversioned) directory for guest agent on EL

2020-01-16 Thread Tomáš Golembiovský
There was no source directory for EL8 guest agent (only EL6 and EL7).

RHBZ#1791802

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 5ec7664b..6ddc488a 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -192,7 +192,7 @@ and install_linux_tools g inspect =
   (match inspect.i_major_version with
| 6 -> Some "el6"
| 7 -> Some "el7"
-   | _ -> None)
+   | _ -> Some "el")
 | "sles" | "suse-based" | "opensuse" -> Some "lp151"
 | _ -> None in
 
-- 
2.24.1


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] 回复: bug report

2020-01-08 Thread Tomáš Golembiovský
On Wed, 8 Jan 2020 21:05:55 +0800
"谢威" <249016...@qq.com> wrote:

> Hi,Tomas:
> 
> 
>   here is the test info: Thanks for your 
> kind help .

The test tool finished OK. Did you try to run you virt-copy-in command
again?

Tomas

> 
> 
>  
>   *
>   IMPORTANT NOTICE
>   *
>   * When reporting bugs, include the COMPLETE, UNEDITED
>   * output below in your bug report.
>   *
>   
> 
> PATH=/usr/java/jdk1.8.0_151/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
> SELinux: Disabled
> guestfs_get_append: (null)
> guestfs_get_autosync: 1
> guestfs_get_backend: libvirt
> guestfs_get_backend_settings: []
> guestfs_get_cachedir: /var/tmp
> guestfs_get_hv: /usr/libexec/qemu-kvm
> guestfs_get_memsize: 500
> guestfs_get_network: 0
> guestfs_get_path: /usr/lib64/guestfs
> guestfs_get_pgroup: 0
> guestfs_get_program: libguestfs-test-tool
> guestfs_get_recovery_proc: 1
> guestfs_get_smp: 1
> guestfs_get_sockdir: /tmp
> guestfs_get_tmpdir: /tmp
> guestfs_get_trace: 0
> guestfs_get_verbose: 1
> host_cpu: x86_64
> Launching appliance, timeout set to 600 seconds.
> libguestfs: launch: program=libguestfs-test-tool
> libguestfs: launch: version=1.38.2rhel=7,release=12.el7_6.2,libvirt
> libguestfs: launch: backend registered: unix
> libguestfs: launch: backend registered: uml
> libguestfs: launch: backend registered: libvirt
> libguestfs: launch: backend registered: direct
> libguestfs: launch: backend=libvirt
> libguestfs: launch: tmpdir=/tmp/libguestfs8AN8TK
> libguestfs: launch: umask=0022
> libguestfs: launch: euid=0
> libguestfs: libvirt version = 4005000 (4.5.0)
> libguestfs: guest random name = guestfs-o0hvxvzsdjoeu7gn
> libguestfs: connect to libvirt
> libguestfs: opening libvirt handle: URI = qemu:///system, auth = 
> default+wrapper, flags = 0
> libguestfs: successfully opened libvirt handle: conn = 0x5616f24bca10
> libguestfs: qemu version (reported by libvirt) = 2012000 (2.12.0)
> libguestfs: get libvirt capabilities
> libguestfs: parsing capabilities XML
> libguestfs: build appliance
> libguestfs: begin building supermin appliance
> libguestfs: run supermin
> libguestfs: command: run: /usr/bin/supermin5
> libguestfs: command: run: \ --build
> libguestfs: command: run: \ --verbose
> libguestfs: command: run: \ --if-newer
> libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock
> libguestfs: command: run: \ --copy-kernel
> libguestfs: command: run: \ -f ext2
> libguestfs: command: run: \ --host-cpu x86_64
> libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d
> libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
> supermin: version: 5.1.19
> supermin: rpm: detected RPM version 4.11
> supermin: package handler: fedora/rpm
> supermin: acquiring lock on /var/tmp/.guestfs-0/lock
> supermin: if-newer: output does not need rebuilding
> libguestfs: finished building supermin appliance
> libguestfs: command: run: qemu-img
> libguestfs: command: run: \ create
> libguestfs: command: run: \ -f qcow2
> libguestfs: command: run: \ -o 
> backing_file=/var/tmp/.guestfs-0/appliance.d/root,backing_fmt=raw
> libguestfs: command: run: \ /tmp/libguestfs8AN8TK/overlay2.qcow2
> Formatting '/tmp/libguestfs8AN8TK/overlay2.qcow2', fmt=qcow2 size=4294967296 
> backing_file=/var/tmp/.guestfs-0/appliance.d/root backing_fmt=raw 
> cluster_size=65536 lazy_refcounts=off refcount_bits=16
> libguestfs: set_socket_create_context: getcon failed: (none): Invalid 
> argument [you can ignore this message if you are not using SELinux + sVirt]
> libguestfs: clear_socket_create_context: setsockcreatecon failed: NULL: 
> Invalid argument [you can ignore this message if you are not using SELinux + 
> sVirt]
> libguestfs: create libvirt XML
> libguestfs: libvirt XML:\n xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"\n; 
>  unit="MiB"500 unit="MiB"500 mode="host-passthrough"\n   fallback="allow"/\n   tickpolicy="catchup"/\n   tickpolicy="delay"/\n   present="no"/\n  udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory 
> usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=/dev/sdb 
> selinux=0 guestfs_verbose=1 TERM=xterm-256color   model="virtio"\nmodel="random"/dev/urandom file="/tmp/libguestfs8AN8TK/scratch1.img"/\ndev="sda" bus="scsi"/\ntype="raw" cache="unsafe"/\ncontroller="0" bus="0" target="0" unit="0"/\n  
>   name="qemu" type="qcow2" cache="unsafe"/\ntype="drive" controller="0" bus="0" target="1" unit="0"/\n  
>path="/tmp/libguestfsn4dNLJ/guestfsd.sock"/\ntype="virtio" name="org.libguestfs.channel.0"/\n  
> value="/var/tmp"/\n  libguestfs: command: run: ls
> libguestfs: command: run: \ -a
> libguestfs: command: run: \ -l
> libguestfs: command: run: \ -R
> libguestfs: command: run: \ -Z /var/tmp/.guestfs-0
> libguestfs: /var/tmp/.guestfs-0:
> libguestfs: drwxr-xr-x root root ?  
>   

Re: [Libguestfs] bug report

2020-01-08 Thread Tomáš Golembiovský
64
> libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d
> libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
> supermin: version: 5.1.19
> supermin: rpm: detected RPM version 4.11
> supermin: package handler: fedora/rpm
> supermin: acquiring lock on /var/tmp/.guestfs-0/lock
> supermin: if-newer: output does not need rebuilding
> libguestfs: finished building supermin appliance
> libguestfs: trace: disk_create "/tmp/libguestfsn1zUMm/overlay2.qcow2" "qcow2" 
> -1 "backingfile:/var/tmp/.guestfs-0/appliance.d/root" "backingformat:raw"
> libguestfs: command: run: qemu-img
> libguestfs: command: run: \ create
> libguestfs: command: run: \ -f qcow2
> libguestfs: command: run: \ -o 
> backing_file=/var/tmp/.guestfs-0/appliance.d/root,backing_fmt=raw
> libguestfs: command: run: \ /tmp/libguestfsn1zUMm/overlay2.qcow2
> qemu-img: /tmp/libguestfsn1zUMm/overlay2.qcow2: A regular file was expected 
> by the 'file' driver, but something else was given
> Could not open backing image to determine size.
> libguestfs: error: qemu-img: /tmp/libguestfsn1zUMm/overlay2.qcow2: qemu-img 
> exited with error status 1, see debug messages above
> libguestfs: trace: disk_create = -1 (error)
> libguestfs: clear_socket_create_context: setsockcreatecon failed: NULL: 
> Invalid argument [you can ignore this message if you are not using SELinux + 
> sVirt]
> libguestfs: trace: launch = -1 (error)
> libguestfs: trace: close
> libguestfs: closing guestfs handle 0x563ac943f000 (state 0)
> libguestfs: command: run: rm
> libguestfs: command: run: \ -rf /tmp/libguestfsn1zUMm
> [root@gz-op-vmhost01 vmdata]#
> 
> 
> 
> 
> 
> 
> 
> 
> 
> [root@gz-op-vmhost01 vmdata]# virt-copy-in /etc/resolv.conf -a 
> 10.188.2.9.sys.img  /etc/
> libguestfs: trace: set_verbose true
> libguestfs: trace: set_verbose = 0
> libguestfs: create: flags = 0, handle = 0x55f344b7f650, program = virt-copy-in
> libguestfs: trace: set_pgroup true
> libguestfs: trace: set_pgroup = 0
> libguestfs: trace: add_drive "10.188.2.9.sys.img"
> libguestfs: trace: add_drive = 0
> libguestfs: trace: is_config
> libguestfs: trace: is_config = 1
> libguestfs: trace: launch
> libguestfs: trace: max_disks
> libguestfs: trace: max_disks = 255
> libguestfs: trace: get_tmpdir
> libguestfs: trace: get_tmpdir = "/tmp"
> libguestfs: trace: version
> libguestfs: trace: version =  release: 2, extra: rhel=7,release=12.el7_6.2,libvirt, 
> libguestfs: trace: get_backend
> libguestfs: trace: get_backend = "libvirt"
> libguestfs: launch: program=virt-copy-in
> libguestfs: launch: version=1.38.2rhel=7,release=12.el7_6.2,libvirt
> libguestfs: launch: backend registered: unix
> libguestfs: launch: backend registered: uml
> libguestfs: launch: backend registered: libvirt
> libguestfs: launch: backend registered: direct
> libguestfs: launch: backend=libvirt
> libguestfs: launch: tmpdir=/tmp/libguestfsHRQGUn
> libguestfs: launch: umask=0022
> libguestfs: launch: euid=0
> libguestfs: libvirt version = 4005000 (4.5.0)
> libguestfs: guest random name = guestfs-yxto5xhpuo3fwlvw
> libguestfs: connect to libvirt
> libguestfs: opening libvirt handle: URI = qemu:///system, auth = 
> default+wrapper, flags = 0
> libguestfs: successfully opened libvirt handle: conn = 0x55f344b800c0
> libguestfs: qemu version (reported by libvirt) = 2012000 (2.12.0)
> libguestfs: get libvirt capabilities
> libguestfs: parsing capabilities XML
> libguestfs: trace: get_backend_setting "force_tcg"
> libguestfs: trace: get_backend_setting = NULL (error)
> libguestfs: trace: get_backend_setting "internal_libvirt_label"
> libguestfs: trace: get_backend_setting = NULL (error)
> libguestfs: trace: get_backend_setting "internal_libvirt_imagelabel"
> libguestfs: trace: get_backend_setting = NULL (error)
> libguestfs: trace: get_backend_setting "internal_libvirt_norelabel_disks"
> libguestfs: trace: get_backend_setting = NULL (error)
> libguestfs: build appliance
> libguestfs: trace: get_cachedir
> libguestfs: trace: get_cachedir = "/var/tmp"
> libguestfs: begin building supermin appliance
> libguestfs: run supermin
> libguestfs: command: run: /usr/bin/supermin5
> libguestfs: command: run: \ --build
> libguestfs: command: run: \ --verbose
> libguestfs: command: run: \ --if-newer
> libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock
> libguestfs: command: run: \ --copy-kernel
> libguestfs: command: run: \ -f ext2
> libguestfs: command: run: \ --host-cpu x86_64
> libguestfs: command: run: \ /usr/lib64/guestfs/supermin.d
> libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
> supermin: version: 5.1.19
> supermin: rpm: detected RPM version 4.11
> supermin: package handler: fedora/rpm
> supermin: acquiring lock on /var/tmp/.guestfs-0/lock
> supermin: if-newer: output does not need rebuilding
> libguestfs: finished building supermin appliance
> libguestfs: trace: disk_create "/tmp/libguestfsHRQGUn/overlay1.qcow2" "qcow2" 
> -1 "backingfile:/var/tmp/.guestfs-0/appliance.d/root" "backingformat:raw"
> libguestfs: command: run: qemu-img
> libguestfs: command: run: \ create
> libguestfs: command: run: \ -f qcow2
> libguestfs: command: run: \ -o 
> backing_file=/var/tmp/.guestfs-0/appliance.d/root,backing_fmt=raw
> libguestfs: command: run: \ /tmp/libguestfsHRQGUn/overlay1.qcow2
> qemu-img: /tmp/libguestfsHRQGUn/overlay1.qcow2: A regular file was expected 
> by the 'file' driver, but something else was given
> Could not open backing image to determine size.
> libguestfs: error: qemu-img: /tmp/libguestfsHRQGUn/overlay1.qcow2: qemu-img 
> exited with error status 1, see debug messages above
> libguestfs: trace: disk_create = -1 (error)
> libguestfs: clear_socket_create_context: setsockcreatecon failed: NULL: 
> Invalid argument [you can ignore this message if you are not using SELinux + 
> sVirt]
> libguestfs: trace: launch = -1 (error)
> libguestfs: trace: close
> libguestfs: closing guestfs handle 0x55f344b7f650 (state 0)
> libguestfs: command: run: rm
> libguestfs: command: run: \ -rf /tmp/libguestfsHRQGUn

-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] (no subject)

2020-01-08 Thread Tomáš Golembiovský
rmin: build: 6680 files, after matching excludefiles
> supermin: build: 6691 files, after adding hostfiles
> supermin: build: 6688 files, after removing unreadable files
> supermin: build: 6691 files, after munging
> supermin: kernel: looking for kernel using environment variables ...
> supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ...
> supermin: kernel: looking for kernels in /boot ...
> supermin: kernel: kernel version of /boot/vmlinuz-4.15.0-72-generic =
> 4.15.0-72-generic (from filename)
> supermin: kernel: picked modules path /lib/modules/4.15.0-72-generic
> supermin: kernel: kernel version of /boot/vmlinuz-4.15.0-54-generic =
> 4.15.0-54-generic (from content)
> supermin: kernel: picked modules path /lib/modules/4.15.0-54-generic
> supermin: kernel: picked vmlinuz /boot/vmlinuz-4.15.0-72-generic
> supermin: kernel: kernel_version 4.15.0-72-generic
> supermin: kernel: modpath /lib/modules/4.15.0-72-generic
> cp: cannot open '/boot/vmlinuz-4.15.0-72-generic' for reading: Permission
> denied

This may be the root cause. Your user cannot read the content of /boot
directory.

Tomas

> supermin: cp -p '/boot/vmlinuz-4.15.0-72-generic'
> '/var/tmp/.guestfs-1000/appliance.d.sxjic2b4/kernel': command failed, see
> earlier errors
> libguestfs: error: /usr/bin/supermin exited with error status 1, see debug
> messages above
> libguestfs: closing guestfs handle 0x55a8c25890d0 (state 0)
> libguestfs: command: run: rm
> libguestfs: command: run: \ -rf /tmp/libguestfsVov1Hm
> teev@teev-HA:~$ ^C
> teev@teev-HA:~$ export libguestfs_debug=1
> teev@teev-HA:~$ export libguestfs_trace=1
> teev@teev-HA:~$ sudo virt-builder debian-9 --output
> /var/lib/libvirt/images/hassio.img --format qcow2 --size 10G
> --root-password password:test123 --hostname hassio
> --firstboot-command "dpkg-reconfigure openssh-server"
> [sudo] passord for teev:
> [   1,6] Downloading: http://libguestfs.org/download/builder/debian-9.xz
> [   2,4] Planning how to build this image
> [   2,4] Uncompressing
> [  16,4] Resizing (using virt-resize) to expand the disk to 10,0G
> virt-builder: error: libguestfs error: qemu-img:
> /var/lib/libvirt/images/hassio.img: qemu-img exited with error status 1.
> To see full error messages you may need to enable debugging.
> Do:
>   export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
> and run the command again.  For further information, read:
>   http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> You can also run 'libguestfs-test-tool' and post the *complete* output
> into a bug report or message to the libguestfs mailing list.
> 
> If reporting bugs, run virt-builder with debugging enabled and include the
> complete output:
> 
>   virt-builder -v -x [...]
> teev@teev-HA:~$


-- 
Tomáš Golembiovský 


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] Extending the nbdkit python plugin

2019-11-21 Thread Tomáš Golembiovský
This may be confusing at first but is not that difficult once you wrap
your head around it.

There are two types of arguments in Python: positional(*) and
keyword(**). There is a rule that all positional arguments are defined
before the keyword arguments. Also once an argument has a default value
it is considered keyword (not positional). There are some nuances for
which is best to reach to some documentation.


> Another possibility is we could encourage existing Python plugins to
> add **kwargs to all functions where we might plausibly add extra
> parameters in future, ie. the above would become:
> 
>   def pwrite (h, buf, offset, **kwargs):
> 
> This still requires all Python plugins to change, but at least they
> would remain backwards compatible with old and new nbdkit.  However I
> couldn't actually work out how to make this work because:
> 
>   >>> def test(a, **kwargs):

Here you defined single positional argument 'a'.

>   ...   pass
>   ... 
>   >>> test(1)
>   >>> test(1,2)

You are passing two positional arguments. A keyword argument has to have
a name. E.g. this will work: test(1, foo=2)

>   Traceback (most recent call last):
> File "", line 1, in 
>   TypeError: test() takes 1 positional argument but 2 were given
> 

Check the attached script for some examples. Hopefully that will help
you get a better grasp.

Tomas

-- 
Tomáš Golembiovský 
#!/usr/bin/env python3

def abc(*args, **kwargs):
print(args)
print(kwargs)

def with_positional(a, b, c, *args, **kwargs):
print(a, b, c)
print(args)
print(kwargs)

# Wrong: cannot define keyword arguments before positional
#def with_keyword(a=None, b=None, c=None, *args, **kwargs):
#pass

def with_keyword(*args, a=None, b=None, c=None, **kwargs):
print(a, b, c)
print(args)
print(kwargs)

# This is also possible
def with_keyword2(*args, a, b, c, **kwargs):
pass
print(a, b, c)
print(args)
print(kwargs)

# (1, 'abc')
# {'foo': 2, 'bar': 3}
abc(1, 'abc', foo=2, bar=3)
# Wrong: cannot pass positional arguments after keyword arguments
#abc(1, 'abc', foo=2, bar=3, 4, 5)
print('---')

# 1 2 3
# (4, 5)
# {'foo': 10, 'bar': 11}
with_positional(1, 2, 3, 4, 5, foo=10, bar=11)
# Wrong: a,b,c are alrady bound to 4,5,6
#with_positional(4, 5, 6, foo=10, bar=11, a=1, b=2, c=3)

# This works as one would expect
with_positional(a=1, b=2, c=3, foo=10, bar=11)
# These two are wrong
#with_positional(4, a=1, b=2, c=3, foo=10, bar=11)
#with_positional(a=1, b=2, c=3, 4, foo=10, bar=11)

print('---')
with_keyword(4, 5, foo=10, bar=11)
with_keyword(4, 5, foo=10, bar=11, a=1, b=2, c=3)

# These two are equivalent
with_keyword2(foo=10, bar=11, a=1, b=2, c=3)
with_keyword2(a=1, b=2, c=3, foo=10, bar=11)
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 1/2] windows: fix detection of qemu-ga installer on RHV

2019-11-21 Thread Tomáš Golembiovský
The detection was incorrectly matching only 32-bit installer on all
architectures.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 5ec7664b..f47d28e0 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -450,14 +450,13 @@ and virtio_iso_path_matches_qemu_ga path inspect =
* elements.
*)
   let lc_name = String.lowercase_ascii (Filename.basename path) in
-  lc_name = "rhev-qga.msi" ||
   match arch, lc_name with
   | ("i386", "qemu-ga-x86.msi")
   | ("i386", "qemu-ga-i386.msi")
-  | ("i386", "RHEV-QGA.msi")
+  | ("i386", "rhev-qga.msi")
   | ("x86_64", "qemu-ga-x64.msi")
   | ("x86_64", "qemu-ga-x86_64.msi")
-  | ("x86_64", "RHEV-QGA64.msi") -> true
+  | ("x86_64", "rhev-qga64.msi")
   | _ -> false
 
 (* The following function is only exported for unit tests. *)
-- 
2.24.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 2/2] windows: small tweaks of qemu-ga firstboot script

2019-11-21 Thread Tomáš Golembiovský
- match log file with script name
- restart manually only after successfull install, this also helps
  debugging because we can log the installer return code

Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_windows.ml | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 5b7a5bfe..0fda1d4e 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -430,7 +430,13 @@ popd
  fun msi_path ->
let fb_script = "\
 echo Installing qemu-ga from " ^ msi_path ^ "
-\"\\" ^ msi_path ^ "\" /qn /forcerestart /l+*vx \"%cd%\\qemu-ga.log\"
+\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\"
+set elvl=!errorlevel!
+echo Done installing qemu-ga error_level=!elvl!
+if !elvl! == 0 (
+  echo Restarting Windows...
+  shutdown /r /f /c \"rebooted by firstboot script\"
+)
 " in
   Firstboot.add_firstboot_script g inspect.i_root
 ("install " ^ msi_path) fb_script;
-- 
2.24.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 0/2] Fixes and tweak to the installation of qemu-ga MSI

2019-11-21 Thread Tomáš Golembiovský
This, together with the changes to common repo are fixes to the installation
qemu-ga MSI.

There is still an issue that I did not figure yet how to fix. On Windows 10 it
fails to register the QEMU-GA service.

Tomáš Golembiovský (2):
  windows: fix detection of qemu-ga installer on RHV
  windows: small tweaks of qemu-ga firstboot script

 v2v/convert_windows.ml | 8 +++-
 v2v/windows_virtio.ml  | 5 ++---
 2 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.24.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 2/2] firstboot: schedule firstboot as delayed task

2019-11-21 Thread Tomáš Golembiovský
Instead of running firstboot scripts during early boot schedule a task
delayed for 1-2 minute.

During the first boot, after virt-v2v conversion, Windows installs the
drivers injected by virit-v2v. When this installation is finished
Windows enforces some kind of internal reboot. This unfortunately
terminates any running firstboot scritps thus killing for example the
installation of qemu-ga MSI.

Hopefully delaying the installtion to some later time can also fix
problem we sometimes saw on Windows 2012R2 when installing RHEV-APT,
where the installer terminated immediately with the error:

  Failed to connect to server. Error: 0x8007045B

Signed-off-by: Tomáš Golembiovský 
---
 mlcustomize/firstboot.ml | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/mlcustomize/firstboot.ml b/mlcustomize/firstboot.ml
index c3ebfd9..b4ca181 100644
--- a/mlcustomize/firstboot.ml
+++ b/mlcustomize/firstboot.ml
@@ -286,10 +286,18 @@ set log=%%firstboot%%\\log.txt
 set scripts=%%firstboot%%\\scripts
 set scripts_done=%%firstboot%%\\scripts-done
 
-call :main >> \"%%log%%\" 2>&1
+call :main %%1 >> \"%%log%%\" 2>&1
 exit /b
 
 :main
+
+if not '%%1' == 'real' (
+REM schedule delayed task
+schtasks.exe /Delete /TN Firstboot /F
+powershell.exe -command \"$d = (get-date).AddSeconds(119); schtasks.exe 
/Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/') /RU 
SYSTEM /TN Firstboot /TR \\\"%%~dpnx0 real\\\"\"
+exit /b
+)
+
 echo starting firstboot service
 
 if not exist \"%%scripts_done%%\" (
-- 
2.24.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 1/2] firstboot: use absolute path to rhsrvany

2019-11-21 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 mlcustomize/firstboot.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mlcustomize/firstboot.ml b/mlcustomize/firstboot.ml
index a8f4ef7..c3ebfd9 100644
--- a/mlcustomize/firstboot.ml
+++ b/mlcustomize/firstboot.ml
@@ -307,7 +307,7 @@ for f in (\"%%scripts%%\"\\*.bat) do (
 )
 
 echo uninstalling firstboot service
-%s -s firstboot uninstall
+\"%%firstboot%%\\%s\" -s firstboot uninstall
 " firstboot_dir_win srvany in
 
 g#write (firstboot_dir // "firstboot.bat")
-- 
2.24.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 0/2] Delay firstboot scripts to some later time

2019-11-21 Thread Tomáš Golembiovský
When firstboot is used from virt-v2v the scripts, if not fast enough, can get
killed by Windows. After windows installs virtio drivers injected by virt-v2v
it performs some internall reboot, stopping all the running services and
killing any running firstboot script. This is problem mostly for MSI installs
(like qemu-ga that was added recently) that can take several seconds to finish.

This change is little bit controversial in fact that it relies on powershell.
This is not available in early versions (without service packs) of XP and 2003
and our support matrix still mentions these Windows versions.

The change can also be problem for those who really wish to perform an action
early in the boot... if there are such users.

Tomáš Golembiovský (2):
  firstboot: use absolute path to rhsrvany
  firstboot: schedule firstboot as delayed task

 mlcustomize/firstboot.ml | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
2.24.0


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] supermin: failed to find a suitable kernel

2019-11-04 Thread Tomáš Golembiovský
_tcg"
> libguestfs: trace: get_backend_setting = NULL (error)
> libguestfs: trace: get_cachedir
> libguestfs: trace: get_cachedir = "/var/tmp"
> libguestfs: begin building supermin appliance
> libguestfs: run supermin
> libguestfs: command: run: /usr/bin/supermin
> libguestfs: command: run: \ --build
> libguestfs: command: run: \ --verbose
> libguestfs: command: run: \ --if-newer
> libguestfs: command: run: \ --lock /var/tmp/.guestfs-0/lock
> libguestfs: command: run: \ --copy-kernel
> libguestfs: command: run: \ -f ext2
> libguestfs: command: run: \ --host-cpu x86_64
> libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
> libguestfs: command: run: \ -o /var/tmp/.guestfs-0/appliance.d
> supermin: version: 5.1.17
> supermin: package handler: debian/dpkg
> supermin: acquiring lock on /var/tmp/.guestfs-0/lock
> supermin: build: /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
> supermin: reading the supermin appliance
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz type gzip base image 
> (tar)
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/daemon.tar.gz type gzip base 
> image (tar)
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/excludefiles type uncompressed 
> excludefiles
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/hostfiles type uncompressed 
> hostfiles
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/init.tar.gz type gzip base image 
> (tar)
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages type uncompressed 
> packages
> supermin: build: visiting 
> /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/udev-rules.tar.gz type gzip base 
> image (tar)
> supermin: mapping package names to installed packages
> supermin: resolving full list of package dependencies
> supermin: build: 188 packages, including dependencies
> supermin: build: 10647 files
> supermin: build: 6483 files, after matching excludefiles
> supermin: build: 6486 files, after adding hostfiles
> supermin: build: 6486 files, after removing unreadable files
> supermin: build: 6489 files, after munging
> supermin: failed to find a suitable kernel (host_cpu=x86_64).
> 
> I looked for kernels in /boot and modules in /lib/modules.
> 
> If this is a Xen guest, and you only have Xen domU kernels
> installed, try installing a fullvirt kernel (only for
> supermin use, you shouldn't boot the Xen guest with it).
> libguestfs: error: /usr/bin/supermin exited with error status 1, see debug 
> messages above
> libguestfs: trace: launch = -1 (error)
> libguestfs: trace: close
> libguestfs: closing guestfs handle 0x5627c93af260 (state 0)
> libguestfs: command: run: rm
> libguestfs: command: run: \ -rf /tmp/libguestfspqGts5
> 
> Can anybody point me the right direction to fix this?
> 
> Thanks a lot
> Klaas
> Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, 
> Hermann Schweizer, Tim Ulbricht.
> Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer 
> 127/137/50792, USt.-IdNr. DE272208908
> 
> ___
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH] v2v: windows: install QEMU Guest Agent MSI

2019-10-08 Thread Tomáš Golembiovský
Use firstboot script to install MSI with QEMU-GA from virtio-win ISO or
oVirt/RHV guest tools ISO.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_windows.ml | 19 +++
 v2v/windows_virtio.ml  | 27 +++
 v2v/windows_virtio.mli |  4 
 3 files changed, 50 insertions(+)

diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 7ea56592c..06122e42a 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -291,6 +291,13 @@ let convert (g : G.guestfs) inspect source output rcaps =
 if Sys.file_exists tool_path then
   configure_vmdp tool_path;
 
+(* Install QEMU Guest Agent unconditionally and warn if missing *)
+let qemu_ga_files = Windows_virtio.copy_qemu_ga g inspect in
+if qemu_ga_files <> [] then (
+configure_qemu_ga qemu_ga_files;
+) else
+warning (f_"QEMU Guest Agent MSI not found on tools ISO/directory. You 
may want to install the guest agent manually after conversion.");
+
 unconfigure_xenpv ();
 unconfigure_prltools ();
 unconfigure_vmwaretools ()
@@ -416,6 +423,18 @@ popd
 Firstboot.add_firstboot_script g inspect.i_root
   "finish vmdp setup" fb_recover_script
 
+ and configure_qemu_ga files =
+   List.iter (
+ fun msi_path ->
+   let fb_script = "\
+echo Installing qemu-ga from " ^ msi_path ^ "
+\"\\" ^ msi_path ^ "\" /qn /forcerestart /l+*vx \"%cd%\\qemu-ga.log\"
+" in
+  Firstboot.add_firstboot_script g inspect.i_root
+("install " ^ msi_path) fb_script;
+) files
+
+
   and unconfigure_xenpv () =
 match xenpv_uninst with
 | None -> () (* nothing to be uninstalled *)
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 56c7a6757..e040eabaf 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -302,6 +302,13 @@ and copy_drivers g inspect driverdir =
 (fun () ->
   error (f_"root directory ‘/’ is missing from the virtio-win directory or 
ISO.\n\nThis should not happen and may indicate that virtio-win or virt-v2v is 
broken in some way.  Please report this as a bug with a full debug log."))
 
+and copy_qemu_ga g inspect =
+  copy_from_virtio_win g inspect "/" "/"
+virtio_iso_path_matches_qemu_ga
+(fun () ->
+  error (f_"root directory ‘/’ is missing from the virtio-win directory or 
ISO.\n\nThis should not happen and may indicate that virtio-win or virt-v2v is 
broken in some way.  Please report this as a bug with a full debug log."))
+
+
 (* Copy all files from virtio_win directory/ISO located in [srcdir]
  * subdirectory and all its subdirectories to the [destdir]. The directory
  * hierarchy is not preserved, meaning all files will be directly in [destdir].
@@ -433,6 +440,26 @@ and virtio_iso_path_matches_guest_os path inspect =
 
   with Not_found -> false
 
+(* Given a path of a file relative to the root of the directory tree
+ * with virtio-win drivers, figure out if it's suitable for the
+ * specific Windows flavor of the current guest.
+ *)
+and virtio_iso_path_matches_qemu_ga path inspect =
+  let { i_arch = arch } = inspect in
+  (* Lowercased path, since the ISO may contain upper or lowercase path
+   * elements.
+   *)
+  let lc_name = String.lowercase_ascii (Filename.basename path) in
+  lc_name = "rhev-qga.msi" ||
+  match arch, lc_name with
+  | ("i386", "qemu-ga-x86.msi")
+  | ("i386", "qemu-ga-i386.msi")
+  | ("i386", "RHEV-QGA.msi")
+  | ("x86_64", "qemu-ga-x64.msi")
+  | ("x86_64", "qemu-ga-x86_64.msi")
+  | ("x86_64", "RHEV-QGA64.msi") -> true
+  | _ -> false
+
 (* The following function is only exported for unit tests. *)
 module UNIT_TESTS = struct
   let virtio_iso_path_matches_guest_os = virtio_iso_path_matches_guest_os
diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
index ae3b7e865..731dbd6f0 100644
--- a/v2v/windows_virtio.mli
+++ b/v2v/windows_virtio.mli
@@ -44,6 +44,10 @@ val install_linux_tools : Guestfs.guestfs -> Types.inspect 
-> unit
 (** installs QEMU Guest Agent on Linux guest OS from the driver directory or
 driver ISO. It is not fatal if we fail to install the agent. *)
 
+val copy_qemu_ga : Guestfs.guestfs -> Types.inspect -> string list
+(** copy MSIs (idealy just one) with QEMU Guest Agent to Windows guest. The
+MSIs are not installed by this function. *)
+
 (**/**)
 
 (* The following function is only exported for unit tests. *)
-- 
2.23.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH] v2v: Allow Windows virtio ISO to be a block device as well as a regular file.

2019-07-04 Thread Tomáš Golembiovský
On Thu,  4 Jul 2019 15:52:20 +0100
"Richard W.M. Jones"  wrote:

> Thanks: Steven Rosenberg
> ---
>  v2v/windows_virtio.ml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

LGTM


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] small question regarding ovirt

2019-04-03 Thread Tomáš Golembiovský
On Sun, 31 Mar 2019 19:44:06 +0100
"Richard W.M. Jones"  wrote:

> On Sat, Mar 30, 2019 at 10:55:43PM +0300, Hetz Ben Hamo wrote:
> > Hi,
> > 
> > Small questoin: when running the P2v hard disk image, and I want to convert
> > a phyical machine to oVirt, to which machine do I connect when the GUI
> > starts? one of the nodes or the hosted engine? (i'm not talking about the
> > URL).  
> 
> You need a machine (or it can be a VM) with virt-v2v installed, and
> that is what you connect to.  It's called the "conversion appliance"
> in the docs.  I can't quite remember if virt-v2v is installed on the
> nodes by default - if it is you could use one of those.

Yes, it is by default on VDSM nodes. So theoretically you should be able
to use those.

Tomas

> If not then
> bring up a VM in oVirt running Fedora/CentOS/whatever and ‘yum install
> virt-v2v’ on it.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> 
> ___
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 4/4] OCaml tools: output messages into JSON for machine readable

2019-03-27 Thread Tomáš Golembiovský
On Fri, 22 Mar 2019 16:33:43 +0100
Pino Toscano  wrote:

> When the machine readable mode is enabled, print all the messages
> (progress, info, warning, and errors) also as JSON in the machine
> readable stream: this way, users can easily parse the status of the
> OCaml tool, and report that back.
> 
> The formatting of the current date time into the RFC 3999 format is done
> in C, because of the lack of OCaml APIs for this.
> ---
>  common/mltools/Makefile.am |  2 +-
>  common/mltools/tools_utils-c.c | 51 ++
>  common/mltools/tools_utils.ml  | 16 +++
>  lib/guestfs.pod| 19 +
>  4 files changed, 87 insertions(+), 1 deletion(-)

ACK

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 0/3] v2v: improve RHV guest tools installation

2019-03-27 Thread Tomáš Golembiovský
On Tue, 26 Mar 2019 18:02:39 +0100
Pino Toscano  wrote:

> This series slightly improves the way qemu-ga is installed from the
> RHV Tools ISO, simplifying the feedback to the user.
> 
> Patch #3 sort of conflicts with patch #2 of a related series by
> Tomáš Golembiovský:
> https://www.redhat.com/archives/libguestfs/2019-February/msg00016.html
> 
> Pino Toscano (3):
>   v2v: linux: add helper functions for pkg arch and extension
>   v2v: try to pick the right arch for qemu-ga pkgs
>   v2v: change the reporting of RHV Tools messages/warnings/error

Ack series

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 0/3] RFC: v2v: add -o json output mode

2019-03-22 Thread Tomáš Golembiovský
On Mon, 25 Feb 2019 17:22:49 +0100
Pino Toscano  wrote:

> This series adds a new output mode for virt-v2v, called -o json.
> It produces local files, just like -o local, although the metadata
> produced is a JSON file with data that v2v collected in the conversion
> process.  This can be useful for converting to unsupported destinations,
> still based on QEMU/KVM.
> 
> In addition to a simple different metadata, it offers a way to relocate
> the disks, with %{...}-like variables (only 3 added ATM, more can be
> added) to change their paths depending on data of the guest/disks.
> 
> Thanks,
> 
> 
> Pino Toscano (3):
>   common/mlpcre: add offset flag for PCRE.matches
>   v2v: add Var_expander
>   v2v: add -o json output mode
> 
>  .gitignore|   1 +
>  common/mlpcre/PCRE.ml |   2 +-
>  common/mlpcre/PCRE.mli|   5 +-
>  common/mlpcre/pcre-c.c|  16 +-
>  common/mlpcre/pcre_tests.ml   |  15 +-
>  v2v/Makefile.am   |  36 +++-
>  v2v/cmdline.ml|  29 +++
>  v2v/create_json.ml| 348 ++
>  v2v/create_json.mli   |  29 +++
>  v2v/dummy.c   |   2 +
>  v2v/output_json.ml| 116 
>  v2v/output_json.mli   |  31 +++
>  v2v/var_expander.ml   |  69 +++
>  v2v/var_expander.mli  |  82 
>  v2v/var_expander_tests.ml | 103 ++
>  v2v/virt-v2v-output-local.pod |  50 +
>  v2v/virt-v2v.pod  |  15 +-
>  17 files changed, 937 insertions(+), 12 deletions(-)
>  create mode 100644 v2v/create_json.ml
>  create mode 100644 v2v/create_json.mli
>  create mode 100644 v2v/dummy.c
>  create mode 100644 v2v/output_json.ml
>  create mode 100644 v2v/output_json.mli
>  create mode 100644 v2v/var_expander.ml
>  create mode 100644 v2v/var_expander.mli
>  create mode 100644 v2v/var_expander_tests.ml
> 

Series LGTM

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs


[Libguestfs] [PATCH] v2v: windows: save log file from rhev-apt installer

2019-02-14 Thread Tomáš Golembiovský
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ý 
---
 v2v/convert_windows.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 1db3c0ea6..7ea56592c 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -378,7 +378,7 @@ echo Wait for PnP to complete
 @echo off
 
 echo installing rhev-apt
-\"\\rhev-apt.exe\" /S /v/qn
+\"\\rhev-apt.exe\" /S /v/qn /v/l*vx \"/v\\\"%cd%\\rhev-apt.log\\\"\"
 
 echo starting rhev-apt
 net start rhev-apt
-- 
2.20.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 0/3] allow alternative guest tools directories for distributions

2019-02-08 Thread Tomáš Golembiovský
First patch just fixes installing guest tools from directory that was broken.
Second patch revamps how virt-v2v chooses from which directory install guest
tools on Linux. Details in commit message.

v2:
- included comments from Pino and Rich
- added test

Tomáš Golembiovský (3):
  v2v: fix path to source when copying files from guest tools directory
  v2v: allow alternative directories for distributions
  v2v: tests: test paths for installation of linux guest tools

 v2v/Makefile.am  |  1 +
 v2v/test-v2v-copy-guest-tools.sh | 87 
 v2v/windows_virtio.ml| 82 ++
 3 files changed, 137 insertions(+), 33 deletions(-)
 create mode 100755 v2v/test-v2v-copy-guest-tools.sh

-- 
2.20.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 3/3] v2v: tests: test paths for installation of linux guest tools

2019-02-08 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/Makefile.am  |  1 +
 v2v/test-v2v-copy-guest-tools.sh | 87 
 2 files changed, 88 insertions(+)
 create mode 100755 v2v/test-v2v-copy-guest-tools.sh

diff --git a/v2v/Makefile.am b/v2v/Makefile.am
index 2312812fb..84667e11d 100644
--- a/v2v/Makefile.am
+++ b/v2v/Makefile.am
@@ -456,6 +456,7 @@ TESTS += \
 if HAVE_LIBVIRT
 TESTS += \
test-v2v-cdrom.sh \
+   test-v2v-copy-guest-tools.sh \
test-v2v-floppy.sh \
test-v2v-in-place.sh \
test-v2v-mac.sh \
diff --git a/v2v/test-v2v-copy-guest-tools.sh b/v2v/test-v2v-copy-guest-tools.sh
new file mode 100755
index 0..e9c1e5b90
--- /dev/null
+++ b/v2v/test-v2v-copy-guest-tools.sh
@@ -0,0 +1,87 @@
+#!/bin/bash -
+# libguestfs virt-v2v test script
+# Copyright (C) 2019 Red Hat Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+# Test copying of guest tools into guest
+
+set -e
+
+$TEST_FUNCTIONS
+slow_test
+skip_if_skipped
+skip_unless_arch x86_64
+
+guestname="fedora-29"
+
+d=test-v2v-copy-guest-tools.d
+disk="$guestname.img"
+xml="$guestname.xml"
+libvirt_uri="test://$abs_builddir/$xml"
+
+rm -f "$disk" "$xml"
+rm -rf $d
+mkdir $d
+
+# Build a guest (using virt-builder).
+virt-builder "$guestname" --quiet -o "$disk" --selinux-relabel
+
+# Create some minimal test metadata.
+cat > "$xml" <
+  
+$guestname
+1048576
+
+  hvm
+  
+
+
+  
+
+
+
+  
+
+  
+
+EOF
+
+export VIRTIO_WIN="$d/fake-tools"
+
+rm -rf $d
+mkdir -p $d
+mkdir -p $VIRTIO_WIN/linux/fedora{,27,29}
+# has: fedora, fedora27, fedora29; should use: fedora29
+$VG virt-v2v --debug-gc -v -x \
+-i libvirt -ic "$libvirt_uri" $guestname \
+-o local -os $d > $d/log 2>&1
+grep '^locating packages in: linux/fedora29, linux/fedora, linux/fc28$' $d/log
+grep "^cd 'test-v2v-copy-guest-tools.d/fake-tools/linux/fedora29' && " $d/log
+
+rm -rf $d
+mkdir -p $d
+mkdir -p $VIRTIO_WIN/linux/fedora{,27}
+# has: fedora, fedora27; should use: fedora
+$VG virt-v2v --debug-gc -v -x \
+-i libvirt -ic "$libvirt_uri" $guestname \
+-o local -os $d > $d/log 2>&1
+grep '^locating packages in: linux/fedora29, linux/fedora, linux/fc28$' $d/log
+grep "^cd 'test-v2v-copy-guest-tools.d/fake-tools/linux/fedora' && " $d/log
+
+# Finished
+rm -r $d
+rm -f "$disk" "$xml"
-- 
2.20.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 2/3] v2v: allow alternative directories for distributions

2019-02-08 Thread Tomáš Golembiovský
Allow multiple alternative directory names for distributions (or
distribution familiy) when installing Linux guest tools packages.
Original naming required that there is a separate directory for every
version of a distribution (e.g. fc28, fc29, ...). This is inconvenient
when users want to keep just a single version of the package for the
distribution.

For each distribution one can have either a common directory (e.g.
fedora) or a versioned directory (fedora28). This can also be combined.
I.e. one can have both `fedora` and `fedora28` in which case `fedora28`
will be used when converting Fedora 28 guest wheres `fedora` will be
used when converting guests with any other Fedora version.

To have better names for unversioned directories the original names
were changed this way:

fc -> fedora
el -> rhel
lp -> suse

The original directory names are kept for backward compatibility and are
aliased to new names as described below. When both new and old name are
present on file system the new name takes precedence.

fc28 -> fedora
el6 -> rhel6
el7 -> rhel7
lp151 -> suse

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 79 +--
 1 file changed, 47 insertions(+), 32 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index a2b59d1ec..9ef4904be 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -184,32 +184,38 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
   )
 
 and install_linux_tools g inspect =
-  let os =
+  let oses =
 match inspect.i_distro with
-| "fedora" -> Some "fc28"
+| "fedora" -> [
+  sprintf "fedora%d" inspect.i_major_version; "fedora"; "fc28"]
 | "rhel" | "centos" | "scientificlinux" | "redhat-based"
 | "oraclelinux" ->
-  (match inspect.i_major_version with
-   | 6 -> Some "el6"
-   | 7 -> Some "el7"
-   | _ -> None)
-| "sles" | "suse-based" | "opensuse" -> Some "lp151"
-| _ -> None in
-
-  match os with
-  | None ->
+  let r = ref [] in
+  List.push_back r (sprintf "rhel%d" inspect.i_major_version);
+  List.push_back_list r (match inspect.i_major_version with
+| 6 -> ["el6"]
+| 7 -> ["el7"]
+| _ -> []);
+  List.push_back r "rhel";
+  !r
+| "sles" | "suse-based" | "opensuse" -> [
+  sprintf "suse%d" inspect.i_major_version; "suse"; "lp151"]
+| _ -> [] in
+
+  match oses with
+  | [] ->
   warning (f_"don't know how to install guest tools on %s-%d")
 inspect.i_distro inspect.i_major_version
-  | Some os ->
-  let src_path = "linux" // os in
+  | oses ->
+  let src_paths = List.map ((//) "linux") oses in
   let dst_path = "/var/tmp" in
-  debug "locating packages in %s" src_path;
+  debug "locating packages in: %s" (String.concat ", " src_paths);
   let packages =
-copy_from_virtio_win g inspect src_path dst_path
+copy_from_virtio_win g inspect src_paths dst_path
  (fun _ _ -> true)
  (fun () ->
-   warning (f_"guest tools directory ‘%s’ is 
missing from the virtio-win directory or ISO.\n\nGuest tools are only provided 
in the RHV Guest Tools ISO, so this can happen if you are using the version of 
virtio-win which contains just the virtio drivers.  In this case only virtio 
drivers can be installed in the guest, and installation of Guest Tools will be 
skipped.")
-   src_path) in
+   warning (f_"none of the guest tools directories 
‘[%s]’ was found on the virtio-win directory or ISO.\n\nGuest tools are only 
provided in the oVirt/RHV Guest Tools ISO, so this can happen if you are using 
the version of virtio-win which contains just the virtio drivers.  In this case 
only virtio drivers can be installed in the guest, and installation of Guest 
Tools will be skipped.")
+  (String.concat ", " src_paths)) in
   debug "done copying %d files" (List.length packages);
   let packages = List.map ((//) dst_path) packages in
   try
@@ -290,30 +296,37 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  [] <> copy_from_virtio_win g inspect "/" driverdir
+  [] <> copy_from_virtio_win g inspect ["/"] driverdir
 virtio_iso_path_matches_guest_os
 (fun () ->
   error (f_"root directory 

[Libguestfs] [PATCH v2 1/3] v2v: fix path to source when copying files from guest tools directory

2019-02-08 Thread Tomáš Golembiovský
The debug message was slightly changed too to better match the similar
message for ISO case. It refers to the root directory instead of the
specific subdirectory inside guest tools.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 92bf3ec60..a2b59d1ec 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -308,10 +308,11 @@ and copy_drivers g inspect driverdir =
 and copy_from_virtio_win g inspect srcdir destdir filter missing =
   let ret = ref [] in
   if is_directory virtio_win then (
-let dir = virtio_win // srcdir in
-debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
+debug "windows: copy_from_virtio_win: guest tools source directory %s"
+  virtio_win;
 
-if not (is_directory srcdir) then missing ()
+let dir = virtio_win // srcdir in
+if not (is_directory dir) then missing ()
 else (
   let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
   let paths = external_command cmd in
-- 
2.20.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 2/2] v2v: allow alternative directories for distributions

2019-02-06 Thread Tomáš Golembiovský
On Wed, 06 Feb 2019 17:02:57 +0100
Pino Toscano  wrote:

> On Wednesday, 6 February 2019 14:11:41 CET Tomáš Golembiovský wrote:
> > > > + * Note that the call may succeed whithout copying any file at all. 
> > > > This may
> > > > + * happen when the source subdirectory exists but is empty or when 
> > > > [filter]
> > > > + * function is too strict to allow any of the files.
> > > 
> > > Not sure why copy_from_virtio_win should allow an empty list as srcdirs.
> > > IMHO it seems better to have it error out on an empty list.
> > >   
> > 
> > This is not what I am trying to say there.  
>  
> I was not commenting on that phrasing, but on the actual behaviour.
> copy_from_virtio_win can be called with srcdirs as empty list, and in
> that case it will do nothing: IMHO this situation is not a valid one.

ok, got it

> 
> -- 
> Pino Toscano


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 2/2] v2v: allow alternative directories for distributions

2019-02-06 Thread Tomáš Golembiovský
> > + * Note that the call may succeed whithout copying any file at all. This 
> > may
> > + * happen when the source subdirectory exists but is empty or when [filter]
> > + * function is too strict to allow any of the files.  
> 
> Not sure why copy_from_virtio_win should allow an empty list as srcdirs.
> IMHO it seems better to have it error out on an empty list.
> 

This is not what I am trying to say there. What I am trying to say is:
you pass non-empty [srcdirs] and there is a matching directory that
fits that request; if this directory contains no files then the call
itself succeeds (because some directory was found) but no files were
copied.

Let me know if you have tips on how to phrase that better.

Tomas


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 2/2] v2v: allow alternative directories for distributions

2019-02-06 Thread Tomáš Golembiovský
On Mon, 28 Jan 2019 17:39:23 +
"Richard W.M. Jones"  wrote:

> On Sat, Jan 26, 2019 at 01:19:59PM +0100, Tomáš Golembiovský wrote:
> > Allow multiple alternative directory names for distributions (or
> > distribution familiy) when installing Linux guest tools packages.
> > Original naming required that there is a separate directory for every
> > version of a distribution (e.g. fc28, fc29, ...). This is inconvenient
> > when users want to keep just a single version of the package for the
> > distribution.
> > 
> > For each distribution one can have either a common directory (e.g.
> > fedora) or a versioned directory (fedora28). This can also be combined.
> > I.e. one can have both `fedora` and `fedora28` in which case `fedora28`
> > will be used when converting Fedora 28 guest wheres `fedora` will be
> > used when converting guests with any other Fedora version.
> > 
> > To have better names for unversioned directories the original names
> > were changed this way:
> > 
> > fc -> fedora
> > el -> rhel
> > lp -> suse
> > 
> > The original directory names are kept for backward compatibility and are
> > aliased to new names as described below. When both new and old name are
> > present on file system the new name takes precedence.
> > 
> > fc28 -> fedora
> > el6 -> rhel6
> > el7 -> rhel7
> > lp151 -> suse  
> 
> Can we use an actual existing scheme like libosinfo ID?

I'm not sure how this would work. Note that we are mapping distro
families to those directories and not just single distributions.


> 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/windows_virtio.ml | 65 +--
> >  1 file changed, 38 insertions(+), 27 deletions(-)
> > 
> > diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
> > index 94c4774b7..cc33d9502 100644
> > --- a/v2v/windows_virtio.ml
> > +++ b/v2v/windows_virtio.ml
> > @@ -186,14 +186,18 @@ let rec install_drivers ((g, _) as reg) inspect rcaps 
> > =
> >  and install_linux_tools g inspect =
> >let os =
> >  match inspect.i_distro with
> > -| "fedora" -> Some "fc28"
> > +| "fedora" -> Some [
> > +  (sprintf "fedora%d" inspect.i_major_version); "fedora"; "fc28"]
> >  | "rhel" | "centos" | "scientificlinux" | "redhat-based"
> > -| "oraclelinux" ->
> > -  (match inspect.i_major_version with
> > -   | 6 -> Some "el6"
> > -   | 7 -> Some "el7"
> > -   | _ -> None)
> > -| "sles" | "suse-based" | "opensuse" -> Some "lp151"
> > +| "oraclelinux" -> Some (
> > +  [(sprintf "rhel%d" inspect.i_major_version)]  
> 
> As a general rule in functional languages function application
> [ie. calling a function] binds tightest.  So:
> 
>   f 1 + 2means:(f 1) + 2
> 
> You don't need the parentheses around the sprintf statement above or
> later in the patch.
>
> 
> > +  @ (match inspect.i_major_version with
> > +   | 6 -> ["el6"]
> > +   | 7 -> ["el7"]
> > +   | _ -> [])
> > +  @ ["rhel"])  
> 
> You could also rewrite the whole awkward list building non-
> functionally.  It would end up like this which seems a whole lot more
> readable to me:
> 
>   let r = ref [] in
>   List.push_back r (sprintf "rhel%d" inspect.i_major_version);
>   List.push_back r (match ...);
>   List.push_back r "rhel";
>   Some r

Rewritten. I don't know if that improved readability but I don't have
any strong preference here.

> 
> > +| "sles" | "suse-based" | "opensuse" -> Some [
> > +  (sprintf "fedora%d" inspect.i_major_version); "suse"; "lp151"]  
> 
> But this is OK, except drop the extra parens around sprintf.
> 
> > +    with Not_found ->
> > +  missing()  
> 
> Needs a space between missing and ‘()’ (and the same later on).
> 
> I wonder if this code would be simpler if we started to use the
> ‘return’ statement:
> 
>   
> https://github.com/libguestfs/libguestfs/blob/b26bd778b58b78eb59503413fd5b41ac23725690/common/mlstdutils/std_utils.mli#L340-L352
> 
> Anyway, looks reasonable.  I keep thinking it needs a test though. 

I'll look into it.

Tomas

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 1/2] v2v: fix path to source when copying files from guest tools directory

2019-02-06 Thread Tomáš Golembiovský
On Mon, 28 Jan 2019 17:24:15 +
"Richard W.M. Jones"  wrote:

> On Sat, Jan 26, 2019 at 01:19:58PM +0100, Tomáš Golembiovský wrote:
> > The debug message was slightly changed too to better match the similar
> > message for ISO case. It refers to the root directory instead of the
> > specific subdirectory inside guest tools.
> > 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/windows_virtio.ml | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
> > index 92bf3ec60..94c4774b7 100644
> > --- a/v2v/windows_virtio.ml
> > +++ b/v2v/windows_virtio.ml
> > @@ -308,10 +308,10 @@ and copy_drivers g inspect driverdir =
> >  and copy_from_virtio_win g inspect srcdir destdir filter missing =
> >let ret = ref [] in
> >if is_directory virtio_win then (
> > -let dir = virtio_win // srcdir in
> > -debug "windows: copy_from_virtio_win: guest tools source directory %s" 
> > dir;
> > +debug "windows: copy_from_virtio_win: guest tools source directory %s" 
> > virtio_win;  
> 
> Be good to put "virtio_win" on the next line.

ack

> 
> > -if not (is_directory srcdir) then missing ()
> > +let dir = virtio_win // srcdir in
> > +if not (is_directory dir) then missing ()  
> 
> Did this code actually work before?  It seems to be checking if
> literally srcdir (as a directory on the host) exists.

Nope, I don't think it has ever worked (srcdir is relative path).

Tomas

> 
> But yes, looks good apart from the overlong line.
> 
> Rich.
> 
> >  else (
> >let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
> >let paths = external_command cmd in
> > -- 
> > 2.20.1
> > 
> > ___
> > Libguestfs mailing list
> > Libguestfs@redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs  
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 2/2] v2v: allow alternative directories for distributions

2019-01-27 Thread Tomáš Golembiovský
On Sat, 26 Jan 2019 19:42:15 +0100
Sandro Bonazzola  wrote:

> Il giorno sab 26 gen 2019, 13:20 Tomáš Golembiovský 
> ha scritto:
> 
> > Allow multiple alternative directory names for distributions (or
> > distribution familiy) when installing Linux guest tools packages.
> > Original naming required that there is a separate directory for every
> > version of a distribution (e.g. fc28, fc29, ...). This is inconvenient
> > when users want to keep just a single version of the package for the
> > distribution.
> >
> > For each distribution one can have either a common directory (e.g.
> > fedora) or a versioned directory (fedora28). This can also be combined.
> > I.e. one can have both `fedora` and `fedora28` in which case `fedora28`
> > will be used when converting Fedora 28 guest wheres `fedora` will be
> > used when converting guests with any other Fedora version.
> >
> > To have better names for unversioned directories the original names
> > were changed this way:
> >
> > fc -> fedora
> > el -> rhel
> >  
> 
> 
> this will cut centos off
> 
> 

Nope, `rhel` directory is used also for CentOS (as well as oraclelinux
and scientific linux).

> 
> > lp -> suse

Similarly here it's SLES as well as Leap.

> >
> > The original directory names are kept for backward compatibility and are
> > aliased to new names as described below. When both new and old name are
> > present on file system the new name takes precedence.
> >
> > fc28 -> fedora
> > el6 -> rhel6
> > el7 -> rhel7
> > lp151 -> suse
> >
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/windows_virtio.ml | 65 +--
> >  1 file changed, 38 insertions(+), 27 deletions(-)

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 0/2] allow alternative guest tools directories for distributions

2019-01-26 Thread Tomáš Golembiovský
First patch just fixes installing guest tools from directory that was broken.
Second patch revamps how virt-v2v chooses from which directory install guest
tools on Linux. Details in commit message.

Tomáš Golembiovský (2):
  v2v: fix path to source when copying files from guest tools directory
  v2v: allow alternative directories for distributions

 v2v/windows_virtio.ml | 67 +--
 1 file changed, 39 insertions(+), 28 deletions(-)

-- 
2.20.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 2/2] v2v: allow alternative directories for distributions

2019-01-26 Thread Tomáš Golembiovský
Allow multiple alternative directory names for distributions (or
distribution familiy) when installing Linux guest tools packages.
Original naming required that there is a separate directory for every
version of a distribution (e.g. fc28, fc29, ...). This is inconvenient
when users want to keep just a single version of the package for the
distribution.

For each distribution one can have either a common directory (e.g.
fedora) or a versioned directory (fedora28). This can also be combined.
I.e. one can have both `fedora` and `fedora28` in which case `fedora28`
will be used when converting Fedora 28 guest wheres `fedora` will be
used when converting guests with any other Fedora version.

To have better names for unversioned directories the original names
were changed this way:

fc -> fedora
el -> rhel
lp -> suse

The original directory names are kept for backward compatibility and are
aliased to new names as described below. When both new and old name are
present on file system the new name takes precedence.

fc28 -> fedora
el6 -> rhel6
el7 -> rhel7
lp151 -> suse

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 65 +--
 1 file changed, 38 insertions(+), 27 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 94c4774b7..cc33d9502 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -186,14 +186,18 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
 and install_linux_tools g inspect =
   let os =
 match inspect.i_distro with
-| "fedora" -> Some "fc28"
+| "fedora" -> Some [
+  (sprintf "fedora%d" inspect.i_major_version); "fedora"; "fc28"]
 | "rhel" | "centos" | "scientificlinux" | "redhat-based"
-| "oraclelinux" ->
-  (match inspect.i_major_version with
-   | 6 -> Some "el6"
-   | 7 -> Some "el7"
-   | _ -> None)
-| "sles" | "suse-based" | "opensuse" -> Some "lp151"
+| "oraclelinux" -> Some (
+  [(sprintf "rhel%d" inspect.i_major_version)]
+  @ (match inspect.i_major_version with
+   | 6 -> ["el6"]
+   | 7 -> ["el7"]
+   | _ -> [])
+  @ ["rhel"])
+| "sles" | "suse-based" | "opensuse" -> Some [
+  (sprintf "fedora%d" inspect.i_major_version); "suse"; "lp151"]
 | _ -> None in
 
   match os with
@@ -201,15 +205,15 @@ and install_linux_tools g inspect =
   warning (f_"don't know how to install guest tools on %s-%d")
 inspect.i_distro inspect.i_major_version
   | Some os ->
-  let src_path = "linux" // os in
+  let src_paths = List.map ((//) "linux") os in
   let dst_path = "/var/tmp" in
-  debug "locating packages in %s" src_path;
+  debug "locating packages in: %s" (String.concat ", " src_paths);
   let packages =
-copy_from_virtio_win g inspect src_path dst_path
+copy_from_virtio_win g inspect src_paths dst_path
  (fun _ _ -> true)
  (fun () ->
-   warning (f_"guest tools directory ‘%s’ is 
missing from the virtio-win directory or ISO.\n\nGuest tools are only provided 
in the RHV Guest Tools ISO, so this can happen if you are using the version of 
virtio-win which contains just the virtio drivers.  In this case only virtio 
drivers can be installed in the guest, and installation of Guest Tools will be 
skipped.")
-   src_path) in
+   warning (f_"none of the guest tools directories 
‘[%s]’ was found on the virtio-win directory or ISO.\n\nGuest tools are only 
provided in the oVirt/RHV Guest Tools ISO, so this can happen if you are using 
the version of virtio-win which contains just the virtio drivers.  In this case 
only virtio drivers can be installed in the guest, and installation of Guest 
Tools will be skipped.")
+  (String.concat ", " src_paths)) in
   debug "done copying %d files" (List.length packages);
   let packages = List.map ((//) dst_path) packages in
   try
@@ -290,29 +294,34 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  [] <> copy_from_virtio_win g inspect "/" driverdir
+  [] <> copy_from_virtio_win g inspect ["/"] driverdir
 virtio_iso_path_matches_guest_os
 (fun () ->
   error (f_"root directory ‘/’ is missing from the virtio-win directory or 
ISO.\n\nThis should not happen 

[Libguestfs] [PATCH 1/2] v2v: fix path to source when copying files from guest tools directory

2019-01-26 Thread Tomáš Golembiovský
The debug message was slightly changed too to better match the similar
message for ISO case. It refers to the root directory instead of the
specific subdirectory inside guest tools.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 92bf3ec60..94c4774b7 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -308,10 +308,10 @@ and copy_drivers g inspect driverdir =
 and copy_from_virtio_win g inspect srcdir destdir filter missing =
   let ret = ref [] in
   if is_directory virtio_win then (
-let dir = virtio_win // srcdir in
-debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
+debug "windows: copy_from_virtio_win: guest tools source directory %s" 
virtio_win;
 
-if not (is_directory srcdir) then missing ()
+let dir = virtio_win // srcdir in
+if not (is_directory dir) then missing ()
 else (
   let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
   let paths = external_command cmd in
-- 
2.20.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH] v2v: -o openstack: Don't echo full commands (RHBZ#1664310).

2019-01-08 Thread Tomáš Golembiovský
On Tue,  8 Jan 2019 14:11:26 +
"Richard W.M. Jones"  wrote:

> They can contain passwords or tokens if for example the
> ‘-oo os-password’ option is used.
> 
> Thanks: Tomáš Golembiovský, Brett Thurber.
> ---
>  v2v/output_openstack.ml | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)

LGTM

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH] v2v: don't fail when virtio-win does not have qemu-ga packages

2018-12-04 Thread Tomáš Golembiovský
On Tue, 4 Dec 2018 23:50:42 +0200
Nikolay Ivanets  wrote:

> вт, 4 груд. 2018, 23:46 Tomáš Golembiovský користувач tgole...@redhat.com
> пише:
> 
> > Regular virtio-win ISO does not have them and maybe never will.
> >
> 
> May I ask why?

Well there's this philosophical question whether the ISO is for Windows
guests only or not. Or whether it should contain only drivers.

But most importantly, nobody asked for this yet. Opening a BZ against
virtio-win by somebody who needs it would be a good start.

Tomas

-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH] v2v: don't fail when virtio-win does not have qemu-ga packages

2018-12-04 Thread Tomáš Golembiovský
It should not be error to use virtio-win ISO that does not have Linux
packages of QEMU Guest Agent. Only oVirt/RHV guest tools ISO has such
packages now. Regular virtio-win ISO does not have them and maybe never
will.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 88 +++
 1 file changed, 55 insertions(+), 33 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 0b9bdfff3..9972e8c88 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -205,7 +205,7 @@ and install_linux_tools g inspect =
   let dst_path = "/var/tmp" in
   debug "locating packages in %s" src_path;
   let packages = copy_from_virtio_win g inspect src_path dst_path
-(fun _ _ -> true) in
+(fun _ _ -> true) true in
   debug "done copying %d files" (List.length packages);
   let packages = List.map ((//) dst_path) packages in
   try
@@ -286,36 +286,49 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  [] <> copy_from_virtio_win g inspect "/" driverdir 
virtio_iso_path_matches_guest_os
+  [] <> copy_from_virtio_win g inspect "/" driverdir
+virtio_iso_path_matches_guest_os false
 
 (* Copy all files from virtio_win directory/ISO located in [srcdir]
  * subdirectory and all its subdirectories to the [destdir]. The directory
  * hierarchy is not preserved, meaning all files will be directly in [destdir].
  * The file list is filtered based on [filter] function.
  *
+ * If [ok_if_missing] is true only warn when [srcdir] is missing, fail with an
+ * error if false.
+ *
  * Returns list of copied files.
  *)
-and copy_from_virtio_win g inspect srcdir destdir filter =
+and copy_from_virtio_win g inspect srcdir destdir filter ok_if_missing =
   let ret = ref [] in
   if is_directory virtio_win then (
 let dir = virtio_win // srcdir in
 debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
 
-let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
-let paths = external_command cmd in
-List.iter (
-  fun path ->
-if filter path inspect then (
-  let source = dir // path in
-  let target_name = String.lowercase_ascii (Filename.basename path) in
-  let target = destdir // target_name in
-  debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
-source target;
-
-  g#write target (read_whole_file source);
-  List.push_front target_name ret
-)
-  ) paths
+if not (is_directory srcdir) then (
+  let msg = f_"cannot locate directory '%s' in virtio-win directory" in
+  if ok_if_missing then (
+warning msg srcdir;
+  )
+  else
+error msg srcdir
+) else (
+  let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
+  let paths = external_command cmd in
+  List.iter (
+fun path ->
+  if filter path inspect then (
+let source = dir // path in
+let target_name = String.lowercase_ascii (Filename.basename path) 
in
+let target = destdir // target_name in
+debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
+  source target;
+
+g#write target (read_whole_file source);
+List.push_front target_name ret
+  )
+) paths
+)
   )
   else if is_regular_file virtio_win then (
 debug "windows: copy_from_virtio_win: guest tools source ISO %s" 
virtio_win;
@@ -327,21 +340,30 @@ and copy_from_virtio_win g inspect srcdir destdir filter =
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
   let srcdir = vio_root ^ "/" ^ srcdir in
-  let paths = g2#find srcdir in
-  Array.iter (
-fun path ->
-  let source = srcdir ^ "/" ^ path in
-  if g2#is_file source ~followsymlinks:false &&
-   filter path inspect then (
-let target_name = String.lowercase_ascii (Filename.basename path) 
in
-let target = destdir ^ "/" ^ target_name in
-debug "windows: copying guest tools bits: '%s:%s' -> '%s'"
-  virtio_win path target;
-
-g#write target (g2#read_file source);
-List.push_front target_name ret
-  )
-) paths;
+  if not (g2#is_dir srcdir) then (
+let msg = f_"cannot locate directory '%s' in virtio-win ISO" in
+if ok_if_missing then
+  warning msg srcdir
+else
+  error msg srcdir
+  )
+  else (
+let paths = g2#find srcdir in
+Array.iter (
+  fun path ->
+let source = srcdir ^ &quo

Re: [Libguestfs] [PATCH v3] v2v: -o openstack: Allow -oo insecure (RHBZ#1651432).

2018-11-20 Thread Tomáš Golembiovský
On Tue, 20 Nov 2018 10:25:10 +
"Richard W.M. Jones"  wrote:

> Previously we allowed arbitrary flags to be passed through to the
> underlying openstack CLI command, provided they have the format
> ‘--key=value’.  We want to pass the ‘--insecure’ flag through, but
> that doesn't have the key=value form.  However a small modification to
> the matching rules would allow this.
> 
> The effect of this change is that you can now use ‘virt-v2v -oo
> insecure’ to turn off SSL certificate validation.  The default is to
> verify the server certificate (which is the default of the openstack
> command).
> ---
>  v2v/output_openstack.ml   | 11 +++
>  v2v/test-v2v-o-openstack.sh   |  2 ++
>  v2v/virt-v2v-output-openstack.pod |  7 +++
>  3 files changed, 16 insertions(+), 4 deletions(-)
> 

LGTM

I would just enhance the commit message little bit. The change allows
you to pass arbitrary argument and not just --insecure. E.g. --validate
(the opposite of --insecure) or --debug and --verbose.


___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v5 1/3] v2v: refactor copy_drivers() in Windows_virtio

2018-11-13 Thread Tomáš Golembiovský
Changed the function to be more generic and renamed.
The only change in behavior is in produced debug messages.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 46 +++
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 9b45c76f5..0096e 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -254,28 +254,39 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  let ret = ref false in
+  [] <> copy_from_virtio_win g inspect "/" driverdir 
virtio_iso_path_matches_guest_os
+
+(* Copy all files from virtio_win directory/ISO located in [srcdir]
+ * subdirectory and all its subdirectories to the [destdir]. The directory
+ * hierarchy is not preserved, meaning all files will be directly in [destdir].
+ * The file list is filtered based on [filter] function.
+ *
+ * Returns list of copied files.
+ *)
+and copy_from_virtio_win g inspect srcdir destdir filter =
+  let ret = ref [] in
   if is_directory virtio_win then (
-debug "windows: copy_drivers: source directory virtio_win %s" virtio_win;
+let dir = virtio_win // srcdir in
+debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
 
-let cmd = sprintf "cd %s && find -L -type f" (quote virtio_win) in
+let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
 let paths = external_command cmd in
 List.iter (
   fun path ->
-if virtio_iso_path_matches_guest_os path inspect then (
-  let source = virtio_win // path in
-  let target = driverdir //
- String.lowercase_ascii (Filename.basename path) in
-  debug "copying virtio driver bits: 'host:%s' -> '%s'"
+if filter path inspect then (
+  let source = dir // path in
+  let target_name = String.lowercase_ascii (Filename.basename path) in
+  let target = destdir // target_name in
+  debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
 source target;
 
   g#write target (read_whole_file source);
-  ret := true
+  List.push_front target_name ret
 )
   ) paths
   )
   else if is_regular_file virtio_win then (
-debug "windows: copy_drivers: source ISO virtio_win %s" virtio_win;
+debug "windows: copy_from_virtio_win: guest tools source ISO %s" 
virtio_win;
 
 try
   let g2 = open_guestfs ~identifier:"virtio_win" () in
@@ -283,19 +294,20 @@ and copy_drivers g inspect driverdir =
   g2#launch ();
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
-  let paths = g2#find vio_root in
+  let srcdir = vio_root // srcdir in
+  let paths = g2#find srcdir in
   Array.iter (
 fun path ->
-  let source = vio_root // path in
+  let source = srcdir // path in
   if g2#is_file source ~followsymlinks:false &&
-   virtio_iso_path_matches_guest_os path inspect then (
-let target = driverdir //
-   String.lowercase_ascii (Filename.basename path) in
-debug "copying virtio driver bits: '%s:%s' -> '%s'"
+   filter path inspect then (
+let target_name = String.lowercase_ascii (Filename.basename path) 
in
+let target = destdir // target_name in
+debug "windows: copying guest tools bits: '%s:%s' -> '%s'"
   virtio_win path target;
 
 g#write target (g2#read_file source);
-ret := true
+List.push_front target_name ret
   )
 ) paths;
   g2#close()
-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v3 1/3] v2v: refactor copy_drivers() in Windows_virtio

2018-11-13 Thread Tomáš Golembiovský
On Wed, 7 Nov 2018 15:43:00 +
"Richard W.M. Jones"  wrote:

> On Wed, Nov 07, 2018 at 12:53:18PM +0100, Tomáš Golembiovský wrote:
> > Changed the function to be more generic and renamed.
> > The only change in behavior is in produced debug messages.
> > 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/windows_virtio.ml | 48 ---
> >  1 file changed, 31 insertions(+), 17 deletions(-)
> > 
> > diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
> > index 9b45c76f5..da02b6c4e 100644
> > --- a/v2v/windows_virtio.ml
> > +++ b/v2v/windows_virtio.ml
> > @@ -254,28 +254,41 @@ and ddb_regedits inspect drv_name drv_pciid =
> >   * been copied.
> >   *)
> >  and copy_drivers g inspect driverdir =
> > -  let ret = ref false in
> > +  List.length (
> > +copy_from_virtio_win g inspect "/" driverdir 
> > virtio_iso_path_matches_guest_os
> > +  ) > 0
> 
> You can write this as:
> 
>   [] <> copy_from_virtio_win g [etc...]
> 
> which is also more efficient because the compiler will optimize it to
> a single test that the function doesn't return a cons.

done

> 
> > +(* Copy all files from virtio_win directory/ISO located in [srcdir]
> > + * subdirectory and all its subdirectories to the [destdir]. The directory
> > + * hierarchy is not preserved, meaning all files will be directly in 
> > [destdir].
> > + * The file list is filtered based on [filter] function.
> > + *
> > + * Returns list of copied files.
> > + *)
> > +and copy_from_virtio_win g inspect srcdir destdir filter =
> > +  let ret = ref [] in
> >if is_directory virtio_win then (
> > -debug "windows: copy_drivers: source directory virtio_win %s" 
> > virtio_win;
> > +let dir = virtio_win // srcdir in
> > +debug "windows: copy_from_virtio_win: guest tools source directory %s" 
> > dir;
> >  
> > -let cmd = sprintf "cd %s && find -L -type f" (quote virtio_win) in
> > +let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
> >  let paths = external_command cmd in
> >  List.iter (
> >fun path ->
> > -if virtio_iso_path_matches_guest_os path inspect then (
> > -  let source = virtio_win // path in
> > -  let target = driverdir //
> > - String.lowercase_ascii (Filename.basename path) in
> > -  debug "copying virtio driver bits: 'host:%s' -> '%s'"
> > +if filter path inspect then (
> > +  let source = dir // path in
> > +  let target_name = String.lowercase_ascii (Filename.basename 
> > path) in
> > +  let target = destdir // target_name in
> > +  debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
> >  source target;
> >  
> >g#write target (read_whole_file source);
> > -  ret := true
> > +  List.push_front target_name ret
> 
> This will return the list of files backwards (if that matters), but is
> also more efficient than using push_back.

I don't believe it matters.

The comments below were applied in separate commit.

Tomas

> 
> >  )
> >) paths
> >)
> >else if is_regular_file virtio_win then (
> > -debug "windows: copy_drivers: source ISO virtio_win %s" virtio_win;
> > +debug "windows: copy_from_virtio_win: guest tools source ISO %s" 
> > virtio_win;
> >  
> >  try
> >let g2 = open_guestfs ~identifier:"virtio_win" () in
> > @@ -283,19 +296,20 @@ and copy_drivers g inspect driverdir =
> >g2#launch ();
> >let vio_root = "/" in
> >g2#mount_ro "/dev/sda" vio_root;
> > -  let paths = g2#find vio_root in
> > +  let srcdir = vio_root // srcdir in
> 
> It doesn't really matter since virt-v2v only ever runs on Linux,
> but strictly speaking this is wrong.  It should be:
> 
>   let srcdir = vio_root ^ "/" ^ srcdir in
> 
> (But using // in the previous part of the code *was* correct).  The
> reason is that this path is evaluated in the libguestfs appliance
> name space, whereas operation // uses host path concatenation
> (would be \ on Windows host for example).
> 
> > +  let paths = g2#find srcdir in
> >Array.iter (
> >  fun path ->
> > -  let source = vio_root // path in
> > +  let source = 

[Libguestfs] [PATCH v5 3/3] v2v: linux: install QEMU-GA (RHBZ#1619665)

2018-11-13 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_linux.ml   |  2 ++
 v2v/windows_virtio.ml  | 32 
 v2v/windows_virtio.mli |  4 
 3 files changed, 38 insertions(+)

diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index e8c64ac1b..a1bafe91a 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -81,6 +81,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
   let rec do_convert () =
 augeas_grub_configuration ();
 
+Windows_virtio.install_linux_tools g inspect;
+
 unconfigure_xen ();
 unconfigure_vbox ();
 unconfigure_vmware ();
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 5d3dbde4d..0b9bdfff3 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -27,6 +27,8 @@ open Regedit
 open Types
 open Utils
 
+module G = Guestfs
+
 let virtio_win =
   try Sys.getenv "VIRTIO_WIN"
   with Not_found ->
@@ -181,6 +183,36 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
  virtio_rng_supported, virtio_ballon_supported, isa_pvpanic_supported)
   )
 
+and install_linux_tools g inspect =
+  let os =
+match inspect.i_distro with
+| "fedora" -> Some "fc28"
+| "rhel" | "centos" | "scientificlinux" | "redhat-based"
+| "oraclelinux" ->
+  (match inspect.i_major_version with
+   | 6 -> Some "el6"
+   | 7 -> Some "el7"
+   | _ -> None)
+| "sles" | "suse-based" | "opensuse" -> Some "lp151"
+| _ -> None in
+
+  match os with
+  | None ->
+  warning (f_"don't know how to install guest tools on %s-%d")
+inspect.i_distro inspect.i_major_version
+  | Some os ->
+  let src_path = "linux" // os in
+  let dst_path = "/var/tmp" in
+  debug "locating packages in %s" src_path;
+  let packages = copy_from_virtio_win g inspect src_path dst_path
+(fun _ _ -> true) in
+  debug "done copying %d files" (List.length packages);
+  let packages = List.map ((//) dst_path) packages in
+  try
+Linux.install_local g inspect packages;
+  with G.Error msg ->
+warning (f_"failed to install QEMU Guest Agent: %s") msg
+
 and add_guestor_to_registry ((g, root) as reg) inspect drv_name drv_pciid =
   let ddb_node = g#hivex_node_get_child root "DriverDatabase" in
 
diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
index 91b3ced45..fa9997829 100644
--- a/v2v/windows_virtio.mli
+++ b/v2v/windows_virtio.mli
@@ -40,6 +40,10 @@ val install_drivers
 virtio devices if we managed to install those, or legacy devices
 if we didn't. *)
 
+val install_linux_tools : Guestfs.guestfs -> Types.inspect -> unit
+(** installs QEMU Guest Agent on Linux guest OS from the driver directory or
+driver ISO. It is not fatal if we fail to install the agent. *)
+
 (**/**)
 
 (* The following function is only exported for unit tests. *)
-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v5 2/3] v2v: fix path construction in Windows_virtio.copy_files()

2018-11-13 Thread Tomáš Golembiovský
Some paths in the function are evaluated in libguestfs environment.
Previous commit copied the invalid construction. This is now fixed.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 0096e..5d3dbde4d 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -294,15 +294,15 @@ and copy_from_virtio_win g inspect srcdir destdir filter =
   g2#launch ();
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
-  let srcdir = vio_root // srcdir in
+  let srcdir = vio_root ^ "/" ^ srcdir in
   let paths = g2#find srcdir in
   Array.iter (
 fun path ->
-  let source = srcdir // path in
+  let source = srcdir ^ "/" ^ path in
   if g2#is_file source ~followsymlinks:false &&
filter path inspect then (
 let target_name = String.lowercase_ascii (Filename.basename path) 
in
-let target = destdir // target_name in
+let target = destdir ^ "/" ^ target_name in
 debug "windows: copying guest tools bits: '%s:%s' -> '%s'"
   virtio_win path target;
 
-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v5 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-13 Thread Tomáš Golembiovský
changes in v5:
- simplified expression in copy_drivers
- new commit fixing path constructions
- indentation fixes

changes in v4:
- fix call to install_local

changes in v2:
- moved copy_drivers above copy_files
- renamed copy_files to copy_from_virtio_win
- renamed install to install_local
- use rpm instead of yum

This installs packages with QEMU Guest Agent when converting Linux machine. The
packages should be available on guest tools ISO. The patches work "as-is" but
probably deserve some more attention:

- it is "abusing" Winows_virtio code but renaming/refactoring everything to
  remove "windows" from the name and use "guest tools" seems like a lot of
  unnecesary work

- support for Debian is missing
  I don't know how to install the package only when all it's dependencies are
  already installed. dpkg cannot be used to check that (simulate the install).
  And attempting to install the package will leave it half-installed (dpkg
  cannot roll-back).

Tomáš Golembiovský (3):
  v2v: refactor copy_drivers() in Windows_virtio
  v2v: fix path construction in Windows_virtio.copy_files()
  v2v: linux: install QEMU-GA (RHBZ#1619665)

 v2v/convert_linux.ml   |  2 ++
 v2v/windows_virtio.ml  | 78 +-
 v2v/windows_virtio.mli |  4 +++
 3 files changed, 67 insertions(+), 17 deletions(-)

-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v4 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-13 Thread Tomáš Golembiovský
On Tue, 13 Nov 2018 13:41:39 +0100
Tomáš Golembiovský  wrote:

> changes in v4:
> - fix call to install_local

v3 was same as v2 because I forgot to commit the changes. 
The difference between v2 and v4 is just one line in the
Linux.install_local call.

Tomas

> 
> changes in v2:
> - moved copy_drivers above copy_files
> - renamed copy_files to copy_from_virtio_win
> - renamed install to install_local
> - use rpm instead of yum
> 
> This installs packages with QEMU Guest Agent when converting Linux machine. 
> The
> packages should be available on guest tools ISO. The patches work "as-is" but
> probably deserve some more attention:
> 
> - it is "abusing" Winows_virtio code but renaming/refactoring everything to
>   remove "windows" from the name and use "guest tools" seems like a lot of
>   unnecesary work
> 
> - support for Debian is missing
>   I don't know how to install the package only when all it's dependencies are
>   already installed. dpkg cannot be used to check that (simulate the install).
>   And attempting to install the package will leave it half-installed (dpkg
>   cannot roll-back).
> 
> Tomáš Golembiovský (3):
>   v2v: refactor copy_drivers() in Windows_virtio
>   v2v: linux: install packages
>   v2v: linux: install QEMU-GA (RHBZ#1619665)
> 
>  v2v/convert_linux.ml   |  2 ++
>  v2v/linux.ml   | 14 
>  v2v/linux.mli  |  3 ++
>  v2v/windows_virtio.ml  | 78 +++++-
>  v2v/windows_virtio.mli |  4 +++
>  5 files changed, 84 insertions(+), 17 deletions(-)
> 
> -- 
> 2.19.1
> 


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v4 2/3] v2v: linux: install packages

2018-11-13 Thread Tomáš Golembiovský
Install packages from local files without touching network.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/linux.ml  | 14 ++
 v2v/linux.mli |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/v2v/linux.ml b/v2v/linux.ml
index 177724e39..966170cdd 100644
--- a/v2v/linux.ml
+++ b/v2v/linux.ml
@@ -31,6 +31,20 @@ let augeas_reload g =
   g#aug_load ();
   debug_augeas_errors g
 
+let rec install_local g { i_package_format = package_format } packages =
+  if packages <> [] then (
+match package_format with
+| "rpm" ->
+  let cmd = [ "rpm"; "--upgrade"; "-v" ] @ packages in
+  let cmd = Array.of_list cmd in
+  ignore (g#command cmd)
+| format ->
+  error (f_"don’t know how to install packages using %s: packages: %s")
+format (String.concat " " packages)
+(* Reload Augeas in case anything changed. *)
+augeas_reload g
+  )
+
 let rec remove g inspect packages =
   if packages <> [] then (
 do_remove g inspect packages;
diff --git a/v2v/linux.mli b/v2v/linux.mli
index 1c604665e..80593cebc 100644
--- a/v2v/linux.mli
+++ b/v2v/linux.mli
@@ -23,6 +23,9 @@ val augeas_reload : Guestfs.guestfs -> unit
 additional debugging information about parsing problems
 that augeas found. *)
 
+val install_local: Guestfs.guestfs -> Types.inspect -> string list -> unit
+(** Install pacakge(s). *)
+
 val remove : Guestfs.guestfs -> Types.inspect -> string list -> unit
 (** Uninstall package(s). *)
 
-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v4 1/3] v2v: refactor copy_drivers() in Windows_virtio

2018-11-13 Thread Tomáš Golembiovský
Changed the function to be more generic and renamed.
The only change in behavior is in produced debug messages.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 48 ---
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 9b45c76f5..da02b6c4e 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -254,28 +254,41 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  let ret = ref false in
+  List.length (
+copy_from_virtio_win g inspect "/" driverdir 
virtio_iso_path_matches_guest_os
+  ) > 0
+
+(* Copy all files from virtio_win directory/ISO located in [srcdir]
+ * subdirectory and all its subdirectories to the [destdir]. The directory
+ * hierarchy is not preserved, meaning all files will be directly in [destdir].
+ * The file list is filtered based on [filter] function.
+ *
+ * Returns list of copied files.
+ *)
+and copy_from_virtio_win g inspect srcdir destdir filter =
+  let ret = ref [] in
   if is_directory virtio_win then (
-debug "windows: copy_drivers: source directory virtio_win %s" virtio_win;
+let dir = virtio_win // srcdir in
+debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
 
-let cmd = sprintf "cd %s && find -L -type f" (quote virtio_win) in
+let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
 let paths = external_command cmd in
 List.iter (
   fun path ->
-if virtio_iso_path_matches_guest_os path inspect then (
-  let source = virtio_win // path in
-  let target = driverdir //
- String.lowercase_ascii (Filename.basename path) in
-  debug "copying virtio driver bits: 'host:%s' -> '%s'"
+if filter path inspect then (
+  let source = dir // path in
+  let target_name = String.lowercase_ascii (Filename.basename path) in
+  let target = destdir // target_name in
+  debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
 source target;
 
   g#write target (read_whole_file source);
-  ret := true
+  List.push_front target_name ret
 )
   ) paths
   )
   else if is_regular_file virtio_win then (
-debug "windows: copy_drivers: source ISO virtio_win %s" virtio_win;
+debug "windows: copy_from_virtio_win: guest tools source ISO %s" 
virtio_win;
 
 try
   let g2 = open_guestfs ~identifier:"virtio_win" () in
@@ -283,19 +296,20 @@ and copy_drivers g inspect driverdir =
   g2#launch ();
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
-  let paths = g2#find vio_root in
+  let srcdir = vio_root // srcdir in
+  let paths = g2#find srcdir in
   Array.iter (
 fun path ->
-  let source = vio_root // path in
+  let source = srcdir // path in
   if g2#is_file source ~followsymlinks:false &&
-   virtio_iso_path_matches_guest_os path inspect then (
-let target = driverdir //
-   String.lowercase_ascii (Filename.basename path) in
-debug "copying virtio driver bits: '%s:%s' -> '%s'"
+   filter path inspect then (
+let target_name = String.lowercase_ascii (Filename.basename path) 
in
+let target = destdir // target_name in
+debug "windows: copying guest tools bits: '%s:%s' -> '%s'"
   virtio_win path target;
 
 g#write target (g2#read_file source);
-ret := true
+List.push_front target_name ret
   )
 ) paths;
   g2#close()
-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v4 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-13 Thread Tomáš Golembiovský
changes in v4:
- fix call to install_local

changes in v2:
- moved copy_drivers above copy_files
- renamed copy_files to copy_from_virtio_win
- renamed install to install_local
- use rpm instead of yum

This installs packages with QEMU Guest Agent when converting Linux machine. The
packages should be available on guest tools ISO. The patches work "as-is" but
probably deserve some more attention:

- it is "abusing" Winows_virtio code but renaming/refactoring everything to
  remove "windows" from the name and use "guest tools" seems like a lot of
  unnecesary work

- support for Debian is missing
  I don't know how to install the package only when all it's dependencies are
  already installed. dpkg cannot be used to check that (simulate the install).
  And attempting to install the package will leave it half-installed (dpkg
  cannot roll-back).

Tomáš Golembiovský (3):
  v2v: refactor copy_drivers() in Windows_virtio
  v2v: linux: install packages
  v2v: linux: install QEMU-GA (RHBZ#1619665)

 v2v/convert_linux.ml   |  2 ++
 v2v/linux.ml   | 14 
 v2v/linux.mli  |  3 ++
 v2v/windows_virtio.ml  | 78 +-
 v2v/windows_virtio.mli |  4 +++
 5 files changed, 84 insertions(+), 17 deletions(-)

-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v4 3/3] v2v: linux: install QEMU-GA (RHBZ#1619665)

2018-11-13 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_linux.ml   |  2 ++
 v2v/windows_virtio.ml  | 30 ++
 v2v/windows_virtio.mli |  4 
 3 files changed, 36 insertions(+)

diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index e8c64ac1b..a1bafe91a 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -81,6 +81,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
   let rec do_convert () =
 augeas_grub_configuration ();
 
+Windows_virtio.install_linux_tools g inspect;
+
 unconfigure_xen ();
 unconfigure_vbox ();
 unconfigure_vmware ();
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index da02b6c4e..73717ead7 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -27,6 +27,8 @@ open Regedit
 open Types
 open Utils
 
+module G = Guestfs
+
 let virtio_win =
   try Sys.getenv "VIRTIO_WIN"
   with Not_found ->
@@ -181,6 +183,34 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
  virtio_rng_supported, virtio_ballon_supported, isa_pvpanic_supported)
   )
 
+and install_linux_tools g inspect =
+  let os = match inspect.i_distro with
+  | "fedora" -> Some "fc28"
+  | "rhel" | "centos" | "scientificlinux" | "redhat-based"
+  | "oraclelinux" -> (match inspect.i_major_version with
+| 6 -> Some "el6"
+| 7 -> Some "el7"
+| _ -> None)
+  | "sles" | "suse-based" | "opensuse" -> Some "lp151"
+  | _ -> None in
+
+  match os with
+  | None ->
+  warning (f_"don't know how to install guest tools on %s-%d")
+inspect.i_distro inspect.i_major_version
+  | Some os ->
+  let src_path = "linux" // os in
+  let dst_path = "/var/tmp" in
+  debug "locating packages in %s" src_path;
+  let packages = copy_from_virtio_win g inspect src_path dst_path
+(fun _ _ -> true) in
+  debug "done copying %d files" (List.length packages);
+  let packages = List.map ((//) dst_path) packages in
+  try
+Linux.install_local g inspect packages;
+  with G.Error msg ->
+warning (f_"failed to install QEMU Guest Agent: %s") msg
+
 and add_guestor_to_registry ((g, root) as reg) inspect drv_name drv_pciid =
   let ddb_node = g#hivex_node_get_child root "DriverDatabase" in
 
diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
index 91b3ced45..fa9997829 100644
--- a/v2v/windows_virtio.mli
+++ b/v2v/windows_virtio.mli
@@ -40,6 +40,10 @@ val install_drivers
 virtio devices if we managed to install those, or legacy devices
 if we didn't. *)
 
+val install_linux_tools : Guestfs.guestfs -> Types.inspect -> unit
+(** installs QEMU Guest Agent on Linux guest OS from the driver directory or
+driver ISO. It is not fatal if we fail to install the agent. *)
+
 (**/**)
 
 (* The following function is only exported for unit tests. *)
-- 
2.19.1

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v3 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-07 Thread Tomáš Golembiovský
On Wed, 7 Nov 2018 17:32:56 +0100
Tomáš Golembiovský  wrote:

> On Wed, 7 Nov 2018 15:31:56 +
> "Richard W.M. Jones"  wrote:
> 
> > On Wed, Nov 07, 2018 at 12:53:17PM +0100, Tomáš Golembiovský wrote:  
> > > changes in v3:
> > > - fix call to install_local
> > > 
> > > changes in v2:
> > > - moved copy_drivers above copy_files
> > > - renamed copy_files to copy_from_virtio_win
> > > - renamed install to install_local
> > > - use rpm instead of yum
> > > 
> > > This installs packages with QEMU Guest Agent when converting Linux 
> > > machine. The
> > > packages should be available on guest tools ISO. The patches work "as-is" 
> > > but
> > > probably deserve some more attention:
> > > 
> > > - it is "abusing" Winows_virtio code but renaming/refactoring everything 
> > > to
> > >   remove "windows" from the name and use "guest tools" seems like a lot of
> > >   unnecesary work
> > 
> > I didn't mean the comment to mean it was abusing Windows_virtio.  It
> > was just a surprise since at the moment Convert_windows is the only
> > consumer of the Windows_virtio code.  However the change is still
> > correct so this doesn't matter, and maybe we can rename the module in
> > future.  
> 
> This was in cover letter before your comment. :)
> 
> >   
> > > - support for Debian is missing
> > >   I don't know how to install the package only when all it's dependencies 
> > > are
> > >   already installed. dpkg cannot be used to check that (simulate the 
> > > install).
> > >   And attempting to install the package will leave it half-installed (dpkg
> > >   cannot roll-back).
> > 
> > Will we actually have Debian packages on the ISO?  
> 
> Yes.
> 
> > 
> > BTW do we actually have an example of the new ISO or virtio-win.rpm I
> > can test against?  
> 
> I am not sure if we have ISO for oVirt already. Let me check.

https://resources.ovirt.org/pub/ovirt-4.2/rpm/el7/noarch/ovirt-guest-tools-iso-4.2-4.el7.noarch.rpm

> 
> Tomas
> 
> > 
> > Rich.
> >   
> > > Tomáš Golembiovský (3):
> > >   v2v: refactor copy_drivers() in Windows_virtio
> > >   v2v: linux: install packages
> > >   v2v: linux: install QEMU-GA (RHBZ#1619665)
> > > 
> > >  v2v/convert_linux.ml   |  2 ++
> > >  v2v/linux.ml   | 14 
> > >  v2v/linux.mli  |  3 ++
> > >  v2v/windows_virtio.ml  | 78 +-
> > >  v2v/windows_virtio.mli |  4 +++
> > >  5 files changed, 84 insertions(+), 17 deletions(-)
> > > 
> > > -- 
> > > 2.19.0
> > > 
> > > _______
> > > Libguestfs mailing list
> > > Libguestfs@redhat.com
> > > https://www.redhat.com/mailman/listinfo/libguestfs
> > 
> > -- 
> > Richard Jones, Virtualization Group, Red Hat 
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > virt-top is 'top' for virtual machines.  Tiny program with many
> > powerful monitoring features, net stats, disk stats, logging, etc.
> > http://people.redhat.com/~rjones/virt-top  
> 
> 
> -- 
> Tomáš Golembiovský 


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v3 3/3] v2v: linux: install QEMU-GA (RHBZ#1619665)

2018-11-07 Thread Tomáš Golembiovský
On Wed, 7 Nov 2018 15:46:49 +
"Richard W.M. Jones"  wrote:

> On Wed, Nov 07, 2018 at 12:53:20PM +0100, Tomáš Golembiovský wrote:
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/convert_linux.ml   |  2 ++
> >  v2v/windows_virtio.ml  | 30 ++
> >  v2v/windows_virtio.mli |  4 
> >  3 files changed, 36 insertions(+)
> > 
> > diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
> > index e8c64ac1b..a1bafe91a 100644
> > --- a/v2v/convert_linux.ml
> > +++ b/v2v/convert_linux.ml
> > @@ -81,6 +81,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
> >let rec do_convert () =
> >  augeas_grub_configuration ();
> >  
> > +Windows_virtio.install_linux_tools g inspect;
> > +
> >  unconfigure_xen ();
> >  unconfigure_vbox ();
> >  unconfigure_vmware ();
> > diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
> > index da02b6c4e..223e7661b 100644
> > --- a/v2v/windows_virtio.ml
> > +++ b/v2v/windows_virtio.ml
> > @@ -27,6 +27,8 @@ open Regedit
> >  open Types
> >  open Utils
> >  
> > +module G = Guestfs
> > +
> >  let virtio_win =
> >try Sys.getenv "VIRTIO_WIN"
> >with Not_found ->
> > @@ -181,6 +183,34 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
> >   virtio_rng_supported, virtio_ballon_supported, isa_pvpanic_supported)
> >)
> >  
> > +and install_linux_tools g inspect =
> > +  let os = match inspect.i_distro with
> > +  | "fedora" -> Some "fc28"
> > +  | "rhel" | "centos" | "scientificlinux" | "redhat-based"
> > +  | "oraclelinux" -> (match inspect.i_major_version with
> > +| 6 -> Some "el6"
> > +| 7 -> Some "el7"
> > +| _ -> None)
> > +  | "sles" | "suse-based" | "opensuse" -> Some "lp151"
> > +  | _ -> None in
> > +
> > +  match os with
> > +  | None ->
> > +  warning (f_"don't know how to install guest tools on %s-%d")
> > +inspect.i_distro inspect.i_major_version
> > +  | Some os ->
> > +  let src_path = "linux" // os in
> > +  let dst_path = "/var/tmp" in
> > +  debug "locating packages in %s" src_path;
> > +  let packages = copy_from_virtio_win g inspect src_path dst_path
> > +(fun _ _ -> true) in
> > +  debug "done copying %d files" (List.length packages);
> > +  let packages = List.map ((//) dst_path) packages in
> > +  try
> > +Linux.install g inspect packages;
> > +  with G.Error msg ->
> > +warning (f_"failed to install QEMU Guest Agent: %s") msg  

I should make the message more generic, like "failed to install guest
tools".


> So this was going to be my question about this.  Here we've decided to
> effectively ignore failure to install qemu-ga.  Should it be an error?

If error is "printed in red" then possibly yes but that's about it. My
opinion is that we should not fail conversion because of this. It is not
a critical component (it does not prevent the guest from booting).


> What's the chance that for a supported guest it might fail?  Do the
> packages have complex dependencies?

It is unlikely on EL, but on Debian there is a dependency (on glib)
which may fail. 

Also the guest OS may be in an inconsistent state which prevents
installation of packages and this may fail. IMHO we're not in a position
to deny user conversion of such guest as it may be totally functional
otherwise.

Tomas


> 
> The patch in general looks OK.
> 
> Rich.
> 
> >  and add_guestor_to_registry ((g, root) as reg) inspect drv_name drv_pciid =
> >let ddb_node = g#hivex_node_get_child root "DriverDatabase" in
> >  
> > diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
> > index 91b3ced45..fa9997829 100644
> > --- a/v2v/windows_virtio.mli
> > +++ b/v2v/windows_virtio.mli
> > @@ -40,6 +40,10 @@ val install_drivers
> >  virtio devices if we managed to install those, or legacy devices
> >  if we didn't. *)
> >  
> > +val install_linux_tools : Guestfs.guestfs -> Types.inspect -> unit
> > +(** installs QEMU Guest Agent on Linux guest OS from the driver directory 
> > or
> > +driver ISO. It is not fatal if we fail to install the agent. *)
> > +
> >  (**/**)
> >  
> >  (* The following function is only exported for unit tests. *)
> > -- 
> > 2.19.0
> > 
> > ___
> > Libguestfs mailing list
> > Libguestfs@redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs  
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v3 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-07 Thread Tomáš Golembiovský
On Wed, 7 Nov 2018 15:31:56 +
"Richard W.M. Jones"  wrote:

> On Wed, Nov 07, 2018 at 12:53:17PM +0100, Tomáš Golembiovský wrote:
> > changes in v3:
> > - fix call to install_local
> > 
> > changes in v2:
> > - moved copy_drivers above copy_files
> > - renamed copy_files to copy_from_virtio_win
> > - renamed install to install_local
> > - use rpm instead of yum
> > 
> > This installs packages with QEMU Guest Agent when converting Linux machine. 
> > The
> > packages should be available on guest tools ISO. The patches work "as-is" 
> > but
> > probably deserve some more attention:
> > 
> > - it is "abusing" Winows_virtio code but renaming/refactoring everything to
> >   remove "windows" from the name and use "guest tools" seems like a lot of
> >   unnecesary work  
> 
> I didn't mean the comment to mean it was abusing Windows_virtio.  It
> was just a surprise since at the moment Convert_windows is the only
> consumer of the Windows_virtio code.  However the change is still
> correct so this doesn't matter, and maybe we can rename the module in
> future.

This was in cover letter before your comment. :)

> 
> > - support for Debian is missing
> >   I don't know how to install the package only when all it's dependencies 
> > are
> >   already installed. dpkg cannot be used to check that (simulate the 
> > install).
> >   And attempting to install the package will leave it half-installed (dpkg
> >   cannot roll-back).  
> 
> Will we actually have Debian packages on the ISO?

Yes.

> 
> BTW do we actually have an example of the new ISO or virtio-win.rpm I
> can test against?

I am not sure if we have ISO for oVirt already. Let me check.

Tomas

> 
> Rich.
> 
> > Tomáš Golembiovský (3):
> >   v2v: refactor copy_drivers() in Windows_virtio
> >   v2v: linux: install packages
> >   v2v: linux: install QEMU-GA (RHBZ#1619665)
> > 
> >  v2v/convert_linux.ml   |  2 ++
> >  v2v/linux.ml   | 14 
> >  v2v/linux.mli  |  3 ++
> >  v2v/windows_virtio.ml  | 78 +-
> >  v2v/windows_virtio.mli |  4 +++
> >  5 files changed, 84 insertions(+), 17 deletions(-)
> > 
> > -- 
> > 2.19.0
> > 
> > ___
> > Libguestfs mailing list
> > Libguestfs@redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs  
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH v3 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-07 Thread Tomáš Golembiovský
On Wed, 07 Nov 2018 13:32:45 +0100
Pino Toscano  wrote:

> On Wednesday, 7 November 2018 12:53:17 CET Tomáš Golembiovský wrote:
> > - support for Debian is missing
> >   I don't know how to install the package only when all it's dependencies 
> > are
> >   already installed.  
> 
> dpkg -i foo.deb

If it were as easy as this. :)

> 
> >   dpkg cannot be used to check that (simulate the install).  
> 
> dpkg --dry-run (the man page lists also --no-act, and --simulate)

The --dry-run does not seem to do much. It does not verify dependencies.
See below.

> 
> >   And attempting to install the package will leave it half-installed (dpkg
> >   cannot roll-back).  
> 
> `dpkg -i` performs a complete installation, doing all the steps needed,
> and leaving the package properly configured if the process is succesfull.

That is assuming everything is OK and the package can be installed. If
there are missing dependencies it leaves the package unpacked in the
system but in un-configured state. This would have to be fixed after next
boot of the guest.

See this:

> root@8e59267e1b89:/# dpkg -l qemu-guest-agent 
>
> dpkg-query: no packages found matching qemu-guest-agent
> root@8e59267e1b89:/# dpkg --simulate --refuse-downgrade --skip-same-version 
> --install /var/tmp/qemu-guest-agent_1%3a2.8+dfsg-6+deb9u4_amd64.deb   
>  
> Selecting previously unselected package qemu-guest-agent. 
>
> (Reading database ... 6498 files and directories currently installed.)
>
> Preparing to unpack .../qemu-guest-agent_1%3a2.8+dfsg-6+deb9u4_amd64.deb ...
> root@8e59267e1b89:/# echo $?
> 0
> root@8e59267e1b89:/# dpkg --refuse-downgrade --skip-same-version --install 
> /var/tmp/qemu-guest-agent_1%3a2.8+dfsg-6+deb9u4_amd64.deb 
>   
> Selecting previously unselected package qemu-guest-agent. 
>
> (Reading database ... 6498 files and directories currently installed.)
> Preparing to unpack .../qemu-guest-agent_1%3a2.8+dfsg-6+deb9u4_amd64.deb ...
> Unpacking qemu-guest-agent (1:2.8+dfsg-6+deb9u4) ...  
>
> dpkg: dependency problems prevent configuration of qemu-guest-agent:  
>
>  qemu-guest-agent depends on libglib2.0-0 (>= 2.37.1); however:
>   Package libglib2.0-0 is not installed.
> 
> dpkg: error processing package qemu-guest-agent (--install):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  qemu-guest-agent
> root@8e59267e1b89:/# dpkg -l qemu-guest-agent
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ NameVersion  Architecture Description
> +++-===---
> iU  qemu-guest-agen 1:2.8+dfsg-6 amd64Guest-side qemu-system agent
> root@8e59267e1b89:/# 

Sadly, dpkg cannot even roll-back in case of errors. 

So far I haven't found any way to check dependencies in advance.

Tomas

> 
> -- 
> Pino Toscano


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v3 1/3] v2v: refactor copy_drivers() in Windows_virtio

2018-11-07 Thread Tomáš Golembiovský
Changed the function to be more generic and renamed.
The only change in behavior is in produced debug messages.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 48 ---
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 9b45c76f5..da02b6c4e 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -254,28 +254,41 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  let ret = ref false in
+  List.length (
+copy_from_virtio_win g inspect "/" driverdir 
virtio_iso_path_matches_guest_os
+  ) > 0
+
+(* Copy all files from virtio_win directory/ISO located in [srcdir]
+ * subdirectory and all its subdirectories to the [destdir]. The directory
+ * hierarchy is not preserved, meaning all files will be directly in [destdir].
+ * The file list is filtered based on [filter] function.
+ *
+ * Returns list of copied files.
+ *)
+and copy_from_virtio_win g inspect srcdir destdir filter =
+  let ret = ref [] in
   if is_directory virtio_win then (
-debug "windows: copy_drivers: source directory virtio_win %s" virtio_win;
+let dir = virtio_win // srcdir in
+debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
 
-let cmd = sprintf "cd %s && find -L -type f" (quote virtio_win) in
+let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
 let paths = external_command cmd in
 List.iter (
   fun path ->
-if virtio_iso_path_matches_guest_os path inspect then (
-  let source = virtio_win // path in
-  let target = driverdir //
- String.lowercase_ascii (Filename.basename path) in
-  debug "copying virtio driver bits: 'host:%s' -> '%s'"
+if filter path inspect then (
+  let source = dir // path in
+  let target_name = String.lowercase_ascii (Filename.basename path) in
+  let target = destdir // target_name in
+  debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
 source target;
 
   g#write target (read_whole_file source);
-  ret := true
+  List.push_front target_name ret
 )
   ) paths
   )
   else if is_regular_file virtio_win then (
-debug "windows: copy_drivers: source ISO virtio_win %s" virtio_win;
+debug "windows: copy_from_virtio_win: guest tools source ISO %s" 
virtio_win;
 
 try
   let g2 = open_guestfs ~identifier:"virtio_win" () in
@@ -283,19 +296,20 @@ and copy_drivers g inspect driverdir =
   g2#launch ();
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
-  let paths = g2#find vio_root in
+  let srcdir = vio_root // srcdir in
+  let paths = g2#find srcdir in
   Array.iter (
 fun path ->
-  let source = vio_root // path in
+  let source = srcdir // path in
   if g2#is_file source ~followsymlinks:false &&
-   virtio_iso_path_matches_guest_os path inspect then (
-let target = driverdir //
-   String.lowercase_ascii (Filename.basename path) in
-debug "copying virtio driver bits: '%s:%s' -> '%s'"
+   filter path inspect then (
+let target_name = String.lowercase_ascii (Filename.basename path) 
in
+let target = destdir // target_name in
+debug "windows: copying guest tools bits: '%s:%s' -> '%s'"
   virtio_win path target;
 
 g#write target (g2#read_file source);
-ret := true
+List.push_front target_name ret
   )
 ) paths;
   g2#close()
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 1/3] v2v: refactor copy_drivers() in Windows_virtio

2018-11-07 Thread Tomáš Golembiovský
Changed the function to be more generic and renamed.
The only change in behavior is in produced debug messages.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 48 ---
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 9b45c76f5..da02b6c4e 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -254,28 +254,41 @@ and ddb_regedits inspect drv_name drv_pciid =
  * been copied.
  *)
 and copy_drivers g inspect driverdir =
-  let ret = ref false in
+  List.length (
+copy_from_virtio_win g inspect "/" driverdir 
virtio_iso_path_matches_guest_os
+  ) > 0
+
+(* Copy all files from virtio_win directory/ISO located in [srcdir]
+ * subdirectory and all its subdirectories to the [destdir]. The directory
+ * hierarchy is not preserved, meaning all files will be directly in [destdir].
+ * The file list is filtered based on [filter] function.
+ *
+ * Returns list of copied files.
+ *)
+and copy_from_virtio_win g inspect srcdir destdir filter =
+  let ret = ref [] in
   if is_directory virtio_win then (
-debug "windows: copy_drivers: source directory virtio_win %s" virtio_win;
+let dir = virtio_win // srcdir in
+debug "windows: copy_from_virtio_win: guest tools source directory %s" dir;
 
-let cmd = sprintf "cd %s && find -L -type f" (quote virtio_win) in
+let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
 let paths = external_command cmd in
 List.iter (
   fun path ->
-if virtio_iso_path_matches_guest_os path inspect then (
-  let source = virtio_win // path in
-  let target = driverdir //
- String.lowercase_ascii (Filename.basename path) in
-  debug "copying virtio driver bits: 'host:%s' -> '%s'"
+if filter path inspect then (
+  let source = dir // path in
+  let target_name = String.lowercase_ascii (Filename.basename path) in
+  let target = destdir // target_name in
+  debug "windows: copying guest tools bits: 'host:%s' -> '%s'"
 source target;
 
   g#write target (read_whole_file source);
-  ret := true
+  List.push_front target_name ret
 )
   ) paths
   )
   else if is_regular_file virtio_win then (
-debug "windows: copy_drivers: source ISO virtio_win %s" virtio_win;
+debug "windows: copy_from_virtio_win: guest tools source ISO %s" 
virtio_win;
 
 try
   let g2 = open_guestfs ~identifier:"virtio_win" () in
@@ -283,19 +296,20 @@ and copy_drivers g inspect driverdir =
   g2#launch ();
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
-  let paths = g2#find vio_root in
+  let srcdir = vio_root // srcdir in
+  let paths = g2#find srcdir in
   Array.iter (
 fun path ->
-  let source = vio_root // path in
+  let source = srcdir // path in
   if g2#is_file source ~followsymlinks:false &&
-   virtio_iso_path_matches_guest_os path inspect then (
-let target = driverdir //
-   String.lowercase_ascii (Filename.basename path) in
-debug "copying virtio driver bits: '%s:%s' -> '%s'"
+   filter path inspect then (
+let target_name = String.lowercase_ascii (Filename.basename path) 
in
+let target = destdir // target_name in
+debug "windows: copying guest tools bits: '%s:%s' -> '%s'"
   virtio_win path target;
 
 g#write target (g2#read_file source);
-ret := true
+List.push_front target_name ret
   )
 ) paths;
   g2#close()
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 2/3] v2v: linux: install packages

2018-11-07 Thread Tomáš Golembiovský
Install packages from local files without touching network.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/linux.ml  | 14 ++
 v2v/linux.mli |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/v2v/linux.ml b/v2v/linux.ml
index 177724e39..966170cdd 100644
--- a/v2v/linux.ml
+++ b/v2v/linux.ml
@@ -31,6 +31,20 @@ let augeas_reload g =
   g#aug_load ();
   debug_augeas_errors g
 
+let rec install_local g { i_package_format = package_format } packages =
+  if packages <> [] then (
+match package_format with
+| "rpm" ->
+  let cmd = [ "rpm"; "--upgrade"; "-v" ] @ packages in
+  let cmd = Array.of_list cmd in
+  ignore (g#command cmd)
+| format ->
+  error (f_"don’t know how to install packages using %s: packages: %s")
+format (String.concat " " packages)
+(* Reload Augeas in case anything changed. *)
+augeas_reload g
+  )
+
 let rec remove g inspect packages =
   if packages <> [] then (
 do_remove g inspect packages;
diff --git a/v2v/linux.mli b/v2v/linux.mli
index 1c604665e..80593cebc 100644
--- a/v2v/linux.mli
+++ b/v2v/linux.mli
@@ -23,6 +23,9 @@ val augeas_reload : Guestfs.guestfs -> unit
 additional debugging information about parsing problems
 that augeas found. *)
 
+val install_local: Guestfs.guestfs -> Types.inspect -> string list -> unit
+(** Install pacakge(s). *)
+
 val remove : Guestfs.guestfs -> Types.inspect -> string list -> unit
 (** Uninstall package(s). *)
 
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 3/3] v2v: linux: install QEMU-GA (RHBZ#1619665)

2018-11-07 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_linux.ml   |  2 ++
 v2v/windows_virtio.ml  | 30 ++
 v2v/windows_virtio.mli |  4 
 3 files changed, 36 insertions(+)

diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index e8c64ac1b..a1bafe91a 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -81,6 +81,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
   let rec do_convert () =
 augeas_grub_configuration ();
 
+Windows_virtio.install_linux_tools g inspect;
+
 unconfigure_xen ();
 unconfigure_vbox ();
 unconfigure_vmware ();
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index da02b6c4e..223e7661b 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -27,6 +27,8 @@ open Regedit
 open Types
 open Utils
 
+module G = Guestfs
+
 let virtio_win =
   try Sys.getenv "VIRTIO_WIN"
   with Not_found ->
@@ -181,6 +183,34 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
  virtio_rng_supported, virtio_ballon_supported, isa_pvpanic_supported)
   )
 
+and install_linux_tools g inspect =
+  let os = match inspect.i_distro with
+  | "fedora" -> Some "fc28"
+  | "rhel" | "centos" | "scientificlinux" | "redhat-based"
+  | "oraclelinux" -> (match inspect.i_major_version with
+| 6 -> Some "el6"
+| 7 -> Some "el7"
+| _ -> None)
+  | "sles" | "suse-based" | "opensuse" -> Some "lp151"
+  | _ -> None in
+
+  match os with
+  | None ->
+  warning (f_"don't know how to install guest tools on %s-%d")
+inspect.i_distro inspect.i_major_version
+  | Some os ->
+  let src_path = "linux" // os in
+  let dst_path = "/var/tmp" in
+  debug "locating packages in %s" src_path;
+  let packages = copy_from_virtio_win g inspect src_path dst_path
+(fun _ _ -> true) in
+  debug "done copying %d files" (List.length packages);
+  let packages = List.map ((//) dst_path) packages in
+  try
+Linux.install g inspect packages;
+  with G.Error msg ->
+warning (f_"failed to install QEMU Guest Agent: %s") msg
+
 and add_guestor_to_registry ((g, root) as reg) inspect drv_name drv_pciid =
   let ddb_node = g#hivex_node_get_child root "DriverDatabase" in
 
diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
index 91b3ced45..fa9997829 100644
--- a/v2v/windows_virtio.mli
+++ b/v2v/windows_virtio.mli
@@ -40,6 +40,10 @@ val install_drivers
 virtio devices if we managed to install those, or legacy devices
 if we didn't. *)
 
+val install_linux_tools : Guestfs.guestfs -> Types.inspect -> unit
+(** installs QEMU Guest Agent on Linux guest OS from the driver directory or
+driver ISO. It is not fatal if we fail to install the agent. *)
+
 (**/**)
 
 (* The following function is only exported for unit tests. *)
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v3 3/3] v2v: linux: install QEMU-GA (RHBZ#1619665)

2018-11-07 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_linux.ml   |  2 ++
 v2v/windows_virtio.ml  | 30 ++
 v2v/windows_virtio.mli |  4 
 3 files changed, 36 insertions(+)

diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index e8c64ac1b..a1bafe91a 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -81,6 +81,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
   let rec do_convert () =
 augeas_grub_configuration ();
 
+Windows_virtio.install_linux_tools g inspect;
+
 unconfigure_xen ();
 unconfigure_vbox ();
 unconfigure_vmware ();
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index da02b6c4e..223e7661b 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -27,6 +27,8 @@ open Regedit
 open Types
 open Utils
 
+module G = Guestfs
+
 let virtio_win =
   try Sys.getenv "VIRTIO_WIN"
   with Not_found ->
@@ -181,6 +183,34 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
  virtio_rng_supported, virtio_ballon_supported, isa_pvpanic_supported)
   )
 
+and install_linux_tools g inspect =
+  let os = match inspect.i_distro with
+  | "fedora" -> Some "fc28"
+  | "rhel" | "centos" | "scientificlinux" | "redhat-based"
+  | "oraclelinux" -> (match inspect.i_major_version with
+| 6 -> Some "el6"
+| 7 -> Some "el7"
+| _ -> None)
+  | "sles" | "suse-based" | "opensuse" -> Some "lp151"
+  | _ -> None in
+
+  match os with
+  | None ->
+  warning (f_"don't know how to install guest tools on %s-%d")
+inspect.i_distro inspect.i_major_version
+  | Some os ->
+  let src_path = "linux" // os in
+  let dst_path = "/var/tmp" in
+  debug "locating packages in %s" src_path;
+  let packages = copy_from_virtio_win g inspect src_path dst_path
+(fun _ _ -> true) in
+  debug "done copying %d files" (List.length packages);
+  let packages = List.map ((//) dst_path) packages in
+  try
+Linux.install g inspect packages;
+  with G.Error msg ->
+warning (f_"failed to install QEMU Guest Agent: %s") msg
+
 and add_guestor_to_registry ((g, root) as reg) inspect drv_name drv_pciid =
   let ddb_node = g#hivex_node_get_child root "DriverDatabase" in
 
diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
index 91b3ced45..fa9997829 100644
--- a/v2v/windows_virtio.mli
+++ b/v2v/windows_virtio.mli
@@ -40,6 +40,10 @@ val install_drivers
 virtio devices if we managed to install those, or legacy devices
 if we didn't. *)
 
+val install_linux_tools : Guestfs.guestfs -> Types.inspect -> unit
+(** installs QEMU Guest Agent on Linux guest OS from the driver directory or
+driver ISO. It is not fatal if we fail to install the agent. *)
+
 (**/**)
 
 (* The following function is only exported for unit tests. *)
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v2 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-07 Thread Tomáš Golembiovský
changes in v2:
- moved copy_drivers above copy_files
- renamed copy_files to copy_from_virtio_win
- renamed install to install_local
- use rpm instead of yum

This installs packages with QEMU Guest Agent when converting Linux machine. The
packages should be available on guest tools ISO. The patches work "as-is" but
probably deserve some more attention:

- it is "abusing" Winows_virtio code but renaming/refactoring everything to
  remove "windows" from the name and use "guest tools" seems like a lot of
  unnecesary work

- support for Debian is missing
  I don't know how to install the package only when all it's dependencies are
  already installed. dpkg cannot be used to check that (simulate the install).
  And attempting to install the package will leave it half-installed (dpkg
  cannot roll-back).

Tomáš Golembiovský (3):
  v2v: refactor copy_drivers() in Windows_virtio
  v2v: linux: install packages
  v2v: linux: install QEMU-GA (RHBZ#1619665)

 v2v/convert_linux.ml   |  2 ++
 v2v/linux.ml   | 14 
 v2v/linux.mli  |  3 ++
 v2v/windows_virtio.ml  | 78 +-
 v2v/windows_virtio.mli |  4 +++
 5 files changed, 84 insertions(+), 17 deletions(-)

-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH v3 2/3] v2v: linux: install packages

2018-11-07 Thread Tomáš Golembiovský
Install packages from local files without touching network.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/linux.ml  | 14 ++
 v2v/linux.mli |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/v2v/linux.ml b/v2v/linux.ml
index 177724e39..966170cdd 100644
--- a/v2v/linux.ml
+++ b/v2v/linux.ml
@@ -31,6 +31,20 @@ let augeas_reload g =
   g#aug_load ();
   debug_augeas_errors g
 
+let rec install_local g { i_package_format = package_format } packages =
+  if packages <> [] then (
+match package_format with
+| "rpm" ->
+  let cmd = [ "rpm"; "--upgrade"; "-v" ] @ packages in
+  let cmd = Array.of_list cmd in
+  ignore (g#command cmd)
+| format ->
+  error (f_"don’t know how to install packages using %s: packages: %s")
+format (String.concat " " packages)
+(* Reload Augeas in case anything changed. *)
+augeas_reload g
+  )
+
 let rec remove g inspect packages =
   if packages <> [] then (
 do_remove g inspect packages;
diff --git a/v2v/linux.mli b/v2v/linux.mli
index 1c604665e..80593cebc 100644
--- a/v2v/linux.mli
+++ b/v2v/linux.mli
@@ -23,6 +23,9 @@ val augeas_reload : Guestfs.guestfs -> unit
 additional debugging information about parsing problems
 that augeas found. *)
 
+val install_local: Guestfs.guestfs -> Types.inspect -> string list -> unit
+(** Install pacakge(s). *)
+
 val remove : Guestfs.guestfs -> Types.inspect -> string list -> unit
 (** Uninstall package(s). *)
 
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Re: [Libguestfs] [PATCH 2/3] v2v: linux: install packages

2018-11-07 Thread Tomáš Golembiovský
On Tue, 6 Nov 2018 11:32:38 +
"Richard W.M. Jones"  wrote:

> On Tue, Nov 06, 2018 at 11:44:14AM +0100, Tomáš Golembiovský wrote:
> > Install packages from local files without touching network.  
> 
> In fact, not limited to local files, but is limited to guests which
> use ‘yum’.  So I think the function needs a better name unless you're
> planning to combine it with
> customize/customize_run.ml:guest_install_command (which would be overkill).

Uh, somehow I totally screwed this up. The plan was to use "rpm".

> 
> > Signed-off-by: Tomáš Golembiovský 
> > ---
> >  v2v/linux.ml  | 19 +++
> >  v2v/linux.mli |  3 +++
> >  2 files changed, 22 insertions(+)
> > 
> > diff --git a/v2v/linux.ml b/v2v/linux.ml
> > index 177724e39..6a5cae512 100644
> > --- a/v2v/linux.ml
> > +++ b/v2v/linux.ml
> > @@ -31,6 +31,25 @@ let augeas_reload g =
> >g#aug_load ();
> >debug_augeas_errors g
> >  
> > +let rec install g inspect packages =
> > +  if packages <> [] then (
> > +do_install g inspect packages;
> > +(* Reload Augeas in case anything changed. *)
> > +augeas_reload g
> > +  )
> > +
> > +and do_install g { i_package_format = package_format } packages =  
> 
> It's purely a matter of style, but it's also possible to nest
> functions, so:
> 
>   let install g inspect packages =
> let do_install () =
>   ...
> in
> if packages <> [] then (
>   do_install ();
>   ...
> 
> Of course you could also inline do_install.

I used the same style as remove(). I will inline the code as I prefer
that.

Tomas

> 
> Rich.
> 
> > +  assert (List.length packages > 0);
> > +  match package_format with
> > +  | "rpm" ->
> > +let cmd = [ "yum"; "--assumeyes"; "install" ] @ packages in
> > +let cmd = Array.of_list cmd in
> > +ignore (g#command cmd)
> > +
> > +  | format ->
> > +error (f_"don’t know how to install packages using %s: packages: %s")
> > +  format (String.concat " " packages)
> > +
> >  let rec remove g inspect packages =
> >if packages <> [] then (
> >  do_remove g inspect packages;
> > diff --git a/v2v/linux.mli b/v2v/linux.mli
> > index 1c604665e..0036f4769 100644
> > --- a/v2v/linux.mli
> > +++ b/v2v/linux.mli
> > @@ -23,6 +23,9 @@ val augeas_reload : Guestfs.guestfs -> unit
> >  additional debugging information about parsing problems
> >  that augeas found. *)
> >  
> > +val install: Guestfs.guestfs -> Types.inspect -> string list -> unit
> > +(** Install pacakge(s). *)
> > +
> >  val remove : Guestfs.guestfs -> Types.inspect -> string list -> unit
> >  (** Uninstall package(s). *)
> >  
> > -- 
> > 2.19.0
> > 
> > ___
> > Libguestfs mailing list
> > Libguestfs@redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs  
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top


-- 
Tomáš Golembiovský 

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 1/3] v2v: refactor copy_drivers() in Windows_virtio

2018-11-06 Thread Tomáš Golembiovský
Changed the function to be more generic and renamed to copy_files.
The only change in behavior is in produced debug messages.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/windows_virtio.ml | 52 ++-
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 9b45c76f5..91649694d 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -250,32 +250,35 @@ and ddb_regedits inspect drv_name drv_pciid =
 [ "Configuration", REG_SZ drv_config ];
   ]
 
-(* Copy the matching drivers to the driverdir; return true if any have
- * been copied.
+(* Copy all files from [srcdir] and all its subdirectories to the [destdir].
+ * The file list is filtered based on [filter] function. Return list of copied
+ * files.
  *)
-and copy_drivers g inspect driverdir =
-  let ret = ref false in
+and copy_files g inspect srcdir destdir filter =
+
+  let ret = ref [] in
   if is_directory virtio_win then (
-debug "windows: copy_drivers: source directory virtio_win %s" virtio_win;
+let dir = virtio_win // srcdir in
+debug "copy_files: guest tools source directory %s" dir;
 
-let cmd = sprintf "cd %s && find -L -type f" (quote virtio_win) in
+let cmd = sprintf "cd %s && find -L -type f" (quote dir) in
 let paths = external_command cmd in
 List.iter (
   fun path ->
-if virtio_iso_path_matches_guest_os path inspect then (
-  let source = virtio_win // path in
-  let target = driverdir //
- String.lowercase_ascii (Filename.basename path) in
-  debug "copying virtio driver bits: 'host:%s' -> '%s'"
+if filter path inspect then (
+  let source = dir // path in
+  let target_name = String.lowercase_ascii (Filename.basename path) in
+  let target = destdir // target_name in
+  debug "copying guest tool bits: 'host:%s' -> '%s'"
 source target;
 
   g#write target (read_whole_file source);
-  ret := true
+  List.push_front target_name ret
 )
   ) paths
   )
   else if is_regular_file virtio_win then (
-debug "windows: copy_drivers: source ISO virtio_win %s" virtio_win;
+debug "copy_files: guest tools source ISO %s" virtio_win;
 
 try
   let g2 = open_guestfs ~identifier:"virtio_win" () in
@@ -283,19 +286,20 @@ and copy_drivers g inspect driverdir =
   g2#launch ();
   let vio_root = "/" in
   g2#mount_ro "/dev/sda" vio_root;
-  let paths = g2#find vio_root in
+  let srcdir = vio_root // srcdir in
+  let paths = g2#find srcdir in
   Array.iter (
 fun path ->
-  let source = vio_root // path in
+  let source = srcdir // path in
   if g2#is_file source ~followsymlinks:false &&
-   virtio_iso_path_matches_guest_os path inspect then (
-let target = driverdir //
-   String.lowercase_ascii (Filename.basename path) in
-debug "copying virtio driver bits: '%s:%s' -> '%s'"
+   filter path inspect then (
+let target_name = String.lowercase_ascii (Filename.basename path) 
in
+let target = destdir // target_name in
+debug "copying guest tool bits: '%s:%s' -> '%s'"
   virtio_win path target;
 
 g#write target (g2#read_file source);
-ret := true
+List.push_front target_name ret
   )
 ) paths;
   g2#close()
@@ -304,6 +308,14 @@ and copy_drivers g inspect driverdir =
   );
   !ret
 
+(* Copy the matching drivers to the driverdir; return true if any have
+ * been copied.
+ *)
+and copy_drivers g inspect driverdir =
+  List.length (
+copy_files g inspect "/" driverdir virtio_iso_path_matches_guest_os
+  ) > 0
+
 (* Given a path of a file relative to the root of the directory tree
  * with virtio-win drivers, figure out if it's suitable for the
  * specific Windows flavor of the current guest.
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 0/3] Install QEMU-GA from oVirt guest tools ISO on Linux

2018-11-06 Thread Tomáš Golembiovský
This installs packages with QEMU Guest Agent when converting Linux machine. The
packages should be available on guest tools ISO. The patches work "as-is" but
probably deserve some more attention:

- it is "abusing" Winows_virtio code but renaming/refactoring everything to
  remove "windows" from the name and use "guest tools" seems like a lot of
  unnecesary work

- support for Debian is missing
  I don't know how to install the package only when all it's dependencies are
  already installed. dpkg cannot be used to check that (simulate the install).
  And attempting to install the package will leave it half-installed (dpkg
  cannot roll-back).

Tomáš Golembiovský (3):
  v2v: refactor copy_drivers() in Windows_virtio
  v2v: linux: install packages
  v2v: linux: install QEMU-GA

 v2v/convert_linux.ml   |  2 ++
 v2v/linux.ml   | 19 ++
 v2v/linux.mli  |  3 ++
 v2v/windows_virtio.ml  | 82 +++---
 v2v/windows_virtio.mli |  5 +++
 5 files changed, 91 insertions(+), 20 deletions(-)

-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 2/3] v2v: linux: install packages

2018-11-06 Thread Tomáš Golembiovský
Install packages from local files without touching network.

Signed-off-by: Tomáš Golembiovský 
---
 v2v/linux.ml  | 19 +++
 v2v/linux.mli |  3 +++
 2 files changed, 22 insertions(+)

diff --git a/v2v/linux.ml b/v2v/linux.ml
index 177724e39..6a5cae512 100644
--- a/v2v/linux.ml
+++ b/v2v/linux.ml
@@ -31,6 +31,25 @@ let augeas_reload g =
   g#aug_load ();
   debug_augeas_errors g
 
+let rec install g inspect packages =
+  if packages <> [] then (
+do_install g inspect packages;
+(* Reload Augeas in case anything changed. *)
+augeas_reload g
+  )
+
+and do_install g { i_package_format = package_format } packages =
+  assert (List.length packages > 0);
+  match package_format with
+  | "rpm" ->
+let cmd = [ "yum"; "--assumeyes"; "install" ] @ packages in
+let cmd = Array.of_list cmd in
+ignore (g#command cmd)
+
+  | format ->
+error (f_"don’t know how to install packages using %s: packages: %s")
+  format (String.concat " " packages)
+
 let rec remove g inspect packages =
   if packages <> [] then (
 do_remove g inspect packages;
diff --git a/v2v/linux.mli b/v2v/linux.mli
index 1c604665e..0036f4769 100644
--- a/v2v/linux.mli
+++ b/v2v/linux.mli
@@ -23,6 +23,9 @@ val augeas_reload : Guestfs.guestfs -> unit
 additional debugging information about parsing problems
 that augeas found. *)
 
+val install: Guestfs.guestfs -> Types.inspect -> string list -> unit
+(** Install pacakge(s). *)
+
 val remove : Guestfs.guestfs -> Types.inspect -> string list -> unit
 (** Uninstall package(s). *)
 
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[Libguestfs] [PATCH 3/3] v2v: linux: install QEMU-GA

2018-11-06 Thread Tomáš Golembiovský
Signed-off-by: Tomáš Golembiovský 
---
 v2v/convert_linux.ml   |  2 ++
 v2v/windows_virtio.ml  | 30 ++
 v2v/windows_virtio.mli |  5 +
 3 files changed, 37 insertions(+)

diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml
index e8c64ac1b..a1bafe91a 100644
--- a/v2v/convert_linux.ml
+++ b/v2v/convert_linux.ml
@@ -81,6 +81,8 @@ let convert (g : G.guestfs) inspect source output rcaps =
   let rec do_convert () =
 augeas_grub_configuration ();
 
+Windows_virtio.install_linux_tools g inspect;
+
 unconfigure_xen ();
 unconfigure_vbox ();
 unconfigure_vmware ();
diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml
index 91649694d..93b4d643e 100644
--- a/v2v/windows_virtio.ml
+++ b/v2v/windows_virtio.ml
@@ -27,6 +27,8 @@ open Regedit
 open Types
 open Utils
 
+module G = Guestfs
+
 let virtio_win =
   try Sys.getenv "VIRTIO_WIN"
   with Not_found ->
@@ -181,6 +183,34 @@ let rec install_drivers ((g, _) as reg) inspect rcaps =
  virtio_rng_supported, virtio_ballon_supported, isa_pvpanic_supported)
   )
 
+and install_linux_tools g inspect =
+  let os = match inspect.i_distro with
+  | "fedora" -> Some "fc28"
+  | "rhel" | "centos" | "scientificlinux" | "redhat-based"
+  | "oraclelinux" -> (match inspect.i_major_version with
+| 6 -> Some "el6"
+| 7 -> Some "el7"
+| _ -> None)
+  | "sles" | "suse-based" | "opensuse" -> Some "lp151"
+  | _ -> None in
+
+  match os with
+  | None ->
+  warning (f_"Don't know how to install guest tools on %s-%d")
+inspect.i_distro inspect.i_major_version
+  | Some os ->
+  let src_path = "linux" // os in
+  let dst_path = "/var/tmp" in
+  debug "locating packages in %s" src_path;
+  let packages = copy_files g inspect src_path dst_path
+(fun _ _ -> true) in
+  debug "done copying %d files" (List.length packages);
+  let packages = List.map ((//) dst_path) packages in
+  try
+Linux.install g inspect packages;
+  with G.Error msg ->
+warning (f_"Failed to install QEMU Guest Agent: %s") msg
+
 and add_guestor_to_registry ((g, root) as reg) inspect drv_name drv_pciid =
   let ddb_node = g#hivex_node_get_child root "DriverDatabase" in
 
diff --git a/v2v/windows_virtio.mli b/v2v/windows_virtio.mli
index 91b3ced45..4558d041b 100644
--- a/v2v/windows_virtio.mli
+++ b/v2v/windows_virtio.mli
@@ -42,6 +42,11 @@ val install_drivers
 
 (**/**)
 
+val install_linux_tools : Guestfs.guestfs -> Types.inspect -> unit
+(** [inspect]
+installs QEMU Guest Agent on Linux guest OS from the driver directory or
+driver ISO. It is not fatal if we fail to install the agent. *)
+
 (* The following function is only exported for unit tests. *)
 module UNIT_TESTS : sig
   val virtio_iso_path_matches_guest_os : string -> Types.inspect -> bool
-- 
2.19.0

___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

  1   2   3   >