If the logfile is owned as root, like could happen if the first run of
virt-manager is done via 'su -c' or similar, virt-manager refustes to
start on subsequent runs under reduced privs. Just log an error and
skip the logfile setup if that happens.
Since we already determine the distro store ahead of time via
check_location and detect_distro, cache the result in the installer
class to save us some network traffic.
This streamlines virt-manager and virt-install implementations, requiring
installer.distro_detect to be called if we want distro detection. As
a side effect, we now get CDROM detection for free.
Many old OSes don't have an EOL date tracked with libosinfo, and
we just treat them as 'supported'. So the default distro list in
the create wizard is wayyy too huge and contains all sorts of
crazy options.
Assume lack of EOL date means 'unsupported', and add a manual whitelist
for some still common distros. We will fix this at the libosinfo level.
We used to enable this for Fedora 18+, because systemd would
autostart a getty on /dev/hvc0 which made 'virsh console' work
out of the box for a login prompt. However now in Fedora
virtio-console is compiled as a module, and systemd doesn't
detect it in time to start a getty. So the benefit of using
it as the default is erased, and we reverted to this.
More info: https://bugzilla.redhat.com/show_bug.cgi?id=1039742
The previous setup of having an OS register a preferred videomodel is
overly simplistic and doesn't cover all our needs. Rework it without any
logic change for now, we will alter the logic in subsequent commits.
libvirt commit
136ad49740f017aabcac48d02d2df6ab7b0195e9
introduce ./hugepages/page/[@size, @unit, @nodeset]
for memory backing.
This patch will add support in virt-install.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Prevent setup_clone from changing the self._clone_macs list so that
further calls will access the same data.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1027576
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Python's os.open() defaults to mode 0777 if not explicitly specified.
Disk image files don't need to be executable, and having them world
readable isn't an ideal situation either. Owner writable and group
readable is probably more than sufficient when initially creating
them.
Signed-off-by: Ron Lee <ron@debian.org>
re-order xml values according to libvirt code.
a) move "blkiotune" "memtune" ahead of "memoryBacking"
b) move "resource" ahead of "pm"
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
And clean up the API mess while we are at it. Treat the key as an opaque
value that users shouldn't depend on.
Besides the improved code clarity and API layout, this will help diagnose
'key error' issues, since we'll see an object name instead of UUID which
is hard to trace back.
Do not load the devices data for each OS as most of this data will
will not be used by virt-manager. It makes the "Create new VM" wizard
faster on the first time it is accessed (~0.5s faster on my machine).
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
It fixes two problems:
i) "ftp://" was accepted as valid URL but then it causes this
exception:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.7/ftplib.py", line 387, in login
resp = self.sendcmd('USER ' + user)
File "/usr/lib64/python2.7/ftplib.py", line 243, in sendcmd
self.putcmd(cmd)
File "/usr/lib64/python2.7/ftplib.py", line 178, in putcmd
self.putline(line)
File "/usr/lib64/python2.7/ftplib.py", line 173, in putline
self.sock.sendall(line)
AttributeError: 'NoneType' object has no attribute 'sendall'
ii) only a cryptic error message "Unable to complete install: '[Errno
-2] Name or service not known'" was showed to users when the DNS
lookup failed. The exception is now intercepted and decorated with
more information.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1086554
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
After commit 7594cef35f,
pylint show a "access to a protected member" warning.
This patch introduces a static method to solve it.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
testCPUMap() tries to open /usr/share/libvirt/cpu_map.xml file
and that fails if libvirt is not installed on the system
or cpu_map.xml path is different.
Force it to use tests/capabilities-xml/cpu_map.xml file instead.
I've noticed that virt-manager took more time to startup after we
started reading OSes data from libosinfo.
Now the libosinfo data is loaded the first time it is accessed,
without pre-loading it.
This could be further improved by not loading completely an _OsVariant
object but only the data that is requested.
With the lazy load optimization (best of 10 attempts):
$ echo yes | time ./virt-xml --connect __virtinst_test__test:////home/gscrivano/src/virt-manager/tests/testdriver.xml,predictable --confirm test --edit --cpu host-passthrough > /dev/null
0.13user 0.02system 0:00.22elapsed 74%CPU (0avgtext+0avgdata 26756maxresident)k
Without (best of 10 attempts):
$ echo yes | time ./virt-xml --connect __virtinst_test__test:////home/gscrivano/src/virt-manager/tests/testdriver.xml,predictable --confirm test --edit --cpu host-passthrough > /dev/null
1.26user 0.04system 0:01.36elapsed 95%CPU (0avgtext+0avgdata 57996maxresident)k
0inputs+16outputs (0major+17499minor)pagefaults 0swaps
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Add a new channel type "spiceport".
Adding a new virtio channel of name org.spice-space.webdav.0 connected
to a Spice port with the same name allows the Spice client to share a
folder.
It also adds aliases for OS names that are different under libosinfo
to maintain backward compatibility.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Remove some "Memory Backing" parameters from --memory,
and keep 'hugepages' for backward compatibility.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Read the list of CPU models trough getCPUModelNames instead of
accessing directly the file cpu_map.xml.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1060316
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
As for the previous patch, this information is not used anywhere and
this information should be retrieved using the libvirt baselineCPU
API.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This information is not used anywhere and there is no way to read
it directly from libvirt without parsing the cpu_map.xml file.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Chen Hanxiao