Re: [Libguestfs] VM name starting with a dash
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
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
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
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
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
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
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.
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.
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
> > 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.
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.
> 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.
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.
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
> > 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
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
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
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
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
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
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
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
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
> > 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
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
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
- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
- 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
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
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
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
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
_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
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.
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
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
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
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
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
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
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
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
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
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
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
> > + * 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
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
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
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
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
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
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).
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
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
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).
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
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
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)
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()
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
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
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
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
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
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)
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
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)
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
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
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
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
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
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)
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)
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
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
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
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
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
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
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
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
