IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The xend toolstack is deprecated upstream. While support needs continue
for this legacy toolstack, the newer libxl toolstack does not need xend
to work. Additionally, libvirt now has drivers for supporting the libxl
toolstack.
This patch changes the check from /var/lib/xend to /var/lib/xen
which is a common path in both toolstacks. Neither the old path nor the
new one actually proves that xend is currently running. It just validates
that xen has been installed on the machine.
Signed-off-by: Charles Arnold <carnold@suse.com>
Do not show only the OS supported stable when stable_defaults is not
used. commit dc0b9bbaaf introduced this
issue.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This adds:
VirtCLIArgument: a single foo=bar mapping
VirtOptionString: A collection of VirtCLIArguments, that parses the whole thing
VirtCLIParser: Represents a single cli option like --disk, --network, etc.
Centralizing this infrastructure opens up a lot of doors for future
improvements, like cli option introspection.
We could specify 'model' for scsi controllers,
that means we could see more than one controllers
with same icon and blank details.
That will confuse users.
This patch will show details of scsi controller device.
And also we could modify scsi controller model
between 'default' and 'virtio-scsi'.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
There were multiple problems with the setting and usage of
hide_unsupported_rhel_options. Due to the fact that the option has
several diferent namings throughout the code, this patch is renaming
it to stable_defaults, which basically says what the option does and
makes it possible to use it without need for more than one negation
(where the old code had up to 4 of them in some places), which also
helps understanding it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
We set virtio-scsi controller index according to
the number of scsi controller in VM.
This patch will set virtio-scsi controller index
via max index in scsi controller list.
How to reproduce:
a)
If we got an VM with two scsi controller:
<controller type='scsi' index='0'>
<controller type='scsi' index='2'>
#reason for index='2':
someone delete a scsi controller with index=1
by virsh
b)
add a virtio-scsi disk by virt-manager
c)
error threw by virt-manager:
libvirtError: XML error: Multiple 'scsi' controllers with index '2'
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
We should not encourage user use device type 'LUN'
if they selected virtio bus.
This patch will prevent user from doing this.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
s/-help/--help
Although '-help' could work, but we should not encourage
this, and also should be same as
the output of 'virt-manager -h' command.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
hashlib's dynamic import hackery makes pylint very sad since it cannot
realize that the module has sha256 member (just created dynamically),
so let's just make it skip this error.
Also remove unused variable in virtinst.cli
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
On first run, the remote URL install handling creates a storage pool
for /var/lib/libvirt/boot on the remote host. After this, it clears
the VirtualConnection's object cache, so the next time all pools are
fetched, it returns an accurate list.
However that clear_cache call wasn't propagated up to virt-manager's
cache. Add a new cb to fix it.
Our validation check might not be up to date, WRT what characters are
acceptable. So if we try to --auto-clone an existing valid VM with
some characters we aren't expecting, we cause ourselves to error.
Just skip the validation and let libvirt complain if something is wrong.
This makes new x86 kvm guests use the host's CPU model as reported by
libvirt capabilities output. This is a reasonable compromise for now
to increase performance while we wait for libvirt/qemu to fix host-model.
Add a preference for changing the default CPU mode/model. The options are:
- default (whatever virt-manager chooses as the default)
- hypervisor default (no <cpu> block, what we've always done)
- nearest host cpu model (just the 'model' from caps->host->cpu)
- copy host cpu (the entire <cpu> block from caps->host)
The setting only applies to KVM guests, not tested with anything else.
The default is left as is for now (hypervisor default).
copy host CPU will one day use mode='host-model', when it does what
we want. At that point we will probably make it the default
95170e8892 added --network=direct
without updating the number of possible values for --network in the
man page.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
