If the parsed option string is just 'none', make it a no-op.
This helps us be backwards compatible: for example, --rng none is
a no-op, but one day we decide to add an rng device by default to
certain VMs, and --rng none is extended to handle that. --rng none
can be added to users command lines and it will give the expected
results regardless of the virt-install version.
Options that already have special 'none' handling need to opt out
of the default behavior.
We don't have any way at the momemnt to synchronously update cached
object lists. So if old_nvram will create a pool for the nvram dir
(/var/lib/libvirt/qemu/nvram), new_nvram won't see that new object
in our cache, will attempt to create it itself, and raise an error.
Next attempts succeed though.
We can avoid this by not even setting new_nvram.path, that step was
redundant anyways since we are setting a vol_install right afterwards.
This way, new_nvram is getting a reference to the parent_pool object
via the vol_install, so it doesn't even check the pool object cache.
Libvirt storage API doesn't support renaming storage volumes so
we need to copy the nvram file and remove the old one.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368922
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This is for xml like:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
</devices>
<qemu:commandline>
<qemu:arg value='-newarg'/>
<qemu:env name='QEMU_ENV' value='VAL'/>
</qemu:commandline>
</domain>
Requires some extensions to the xmlbuilder infrastructure
Similar to what we do with libvirt. Was never really relevant before,
but some of the namespace XML stuff can be a bit noisy even though it
doesn't have any functional impact that I can tell
Libvirt doesn't support creating volumes for some storage pools,
don't generate default clone_path for these storage pools.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1420190
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If we don't default to clone the disk in question don't try to generate
and assign default clone_path, this will force user to select the path
explicitly and avoid some unnecessary errors in debug log.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Both StorageCreator and StorageBackend should use the same logic
to detect the disk type. Now if the target is block device we will
detect it correctly.
The check for block type doesn't make sense because that code is
executed only for local cloning without Libvirt help which is the
only way how we can clone some block disks.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1420187
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Since we only attempt to add a default USB controller for x86, match
it by only trying to add redir devices on x86 as well. Fixes a uitests
failure for ppc testing, since the test:/// driver doesn't add an
implied USB controller, and libvirt now validates that one was provided.
Clears the existing CPU config if user picks 'Application Default'
in the virt-manager UI, since otherwise we might leave a stale vendor
or flags defined.
Similarly to virt-install --listen=none, add a combobox to select
the listen type: "address" or "none" for now, as suggested by Pavel
Hrdina.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Cole Robinson