The current order of check operations is wrong. First we set the new
path for the disk in question and after that we check whether some
guest already uses a disk with the same path.
The issue is that virt-manager returns a cached list of guests in
path_in_use_by() and the cached guest has the disk path already
updated.
Ideally we don't update the path at all, but we do it to run some
checks before the path is actually changed. In order to fix the
referenced bug, change the order of check operations.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1453094
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
libvirt supports guest CPU cache by commit df13c0b, So add this feature
to virt-install to configure cpu L3 cache mode.
Currently, The valid values are 'passthrough', 'emulate' or 'disable'.
say:
--cpu host-passthrough,cache.mode=passthrough
or
--cpu $CPU,cache.mode=emulate,cache.level=3
or
--cpu $CPU,cache.mode=disable
Signed-off-by: Lin Ma <lma@suse.com>
The Ubuntu c recognition was looking for a file .disk/mini-info.
However, the correct name is .disk/info.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
If initialization of new object fails we put it into blacklist and
newer parse it again until virt-manager is restarted. This helps to
reduce number of failures if some object fails initialization every
time.
However, there are some cases where we put object into blacklist
incorrectly. One of the cases is while creating new storage pool.
If the storage pool requires to be build before started but user
doesn't check to build it as well the start of the new storage pool
fails. The issue is that at first we define that object which triggers
a lifecycle event for storage pool and queues new poll operation over
storage pools. Before the poll operation starts the starting of the
storage pools fails and we undefine that storage pool before it is
initialized. The initialization fails and the storage pool is never
managed from that point.
This patch modifies the blacklist to allow 3 failures before we give up
on a specific object and if the object is initialized without error
we remove it from blacklist completely.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446486
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1093394
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Graphics devices has a new XML element to configure UNIX socket path:
<graphics type='vnc' socket='/path/to/socket'>
<listen type='socket' socket='/path/to/socket'/>
</graphics>
<graphics type='spice'>
<listen type='socket' socket='/path/to/socket'/>
</graphics>
and as you can see SPICE uses only the new XML element. For VNC the
old 'socket' attribute is for backward compatibility.
In order to connect to SPICE graphics on remote host using SSH tunnel
we need to get the UNIX socket path from <listen> element.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441127
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Using "listens.*" allows better configuration of listen elements for
graphics devices. Currently the only way how to configure a listen
type is to abuse "listen" parameter and there is no way how to configure
exact "network".
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The default port and tlsPort should be configured only if no listen
type was specified or the listen type is "address" or "network".
For other listen types the port and tlsPort doesn't make sense.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1488480
This also fixes an issue with floppy not showing at all, the proper
boot.dev name is 'fd' but we were looking for 'floppy'.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There are multiple models of the panic device, the address type is only
one and is valid only for "isa" model.
To not break the virt-install/virt-xml the command line parser needs to
be updated. Before this patch there was only one parameter that
configured the "iobase". Now the first parameter configures a model
but to keep it backward compatible it follows these rules:
1. there is only one parameter and it matches known model:
--panic isa
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
2. there is only one parameter and it doesn't match any model:
--panic 0x505
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
3. there are two parameters:
--panic isa,iobase=0x505
<panic model='isa'>
<address iobase='0x505' type='isa'/>
</panic>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This is advanced configuration and it's not required to configure
at all to have a working panic device.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The panic device has an address element but it's not the same as for
other devices. Panic device can have only one address type "isa" with
only one additional attribute "iobase". That attribute is configured
by separate argument.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The install kernel and intrd files are located in <url-prefix>/generic
of the Debian and Ubuntu s390x install trees. Further they follow a
different naming scheme than on x86. Adjust the url fetching accordingly.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
The message when failing to connect can be misleading as package names
will differ per Distribution as well as not apply for e.g. self built
binaries.
This changes the message in a way to be more generic not implying literal
package names.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Lin Ma