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 virt-manager application generates invalid guest XML when a
spapr-vio SCSI model controller is changed to a virtio-scsi model controller.
1. Create a guest
2. Add an spapr-vio controller to the guest via this gui path:
->Add Hardware
->Controller
->Type SCSI
->Model Hypervisor default
At this point, there will be a valid spapr-vio SCSI controller defined:
<controller type='scsi' index='0'>
<address type='spapr-vio' reg='0x2000'/>
</controller>
3.Now modify the above SCSI controller using this gui path:
->Choose "Controller sPAPR SCSI" on left pane
->Choose "VirtIO SCSI" for the Model on the right pane
->Apply
At this point, there will be a SCSI controller definition which is invalid due to an incorrect address type:
~# virsh dumpxml dotg2|grep -A2 -i scsi
<controller type='scsi' index='0' model='virtio-scsi'>
<address type='spapr-vio' reg='0x2000'/>
</controller>
Any attempt to start the guest will throw this error:
error: Failed to start domain dotg2
error: internal error: process exited while connecting to monitor: 2016-12-02T17:45:12.989165Z qemu-system-ppc64le: -device virtio-scsi-pci,id=scsi0,reg=0x2000: Property '.reg' not found
virt-manager fails to realize that the address type needs to be changed to a PCI address for a virtio-scsi controller.
If you change the model, you are supposed to leave the address field empty, so that libvirt sets it correctly. Or change the address field also appropriately.
Note that this bug can be reproduced entirely within virt-manager. No manual editing of guest XML is being done here. So, fix is to make virt-manager delete the address field when the SCSI controller model is changed, allowing libvirt to automatically assign a new address with the correct type.
Signed-off-by: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
such as a VM is active.
This patch will disable 'Clone' label in VMActionMenu
if we can't clone a VM,
as same as we did for 'Clone' button in clone ui page.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
libvirt has supported the migration V3 protocol for many years now.
A nice feature of the virDomainMigrate3 API is that it will detect
the protocol version supported by the underlying hypervisor,
including whether it supports the extensible parameters variant,
and call the hypervisor API with parameters fixed up as needed.
Change virt-manager to use the virDomainMigrate3 API, allowing
migration to work with hypervisors that only support the extensible
parameters variant of the migration V3 API.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
If password for console is saved currently there is no way how to tell
virt-manager to forget that password. This patch improves the authentication
page in order to provide a way how to forget password simply by unchecking the
"Save this password in your keyring".
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Function virDomainOpenGraphicsFD() from libvirt can return -1
But in this case libvirt-python will raise an exception.
We should handle this case and return -1 as invalid FD.
In commit 5c451b64 Viewer._open() there is a code to open
graphics console in case of invalid GraphicsFD.
(crobinso: also log the error message)
This allows to connect to VM without any display listening socket, the
fd passing is done through libvirt connection.
Furthermore, since it uses unix socket, spice can use virgl locally
with texture sharing. This effectively enables spice-gtk to display
local virgl rendering.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
This UI exposed the old NUMA allocation policy detailed in the last commit.
It's very much sub-optimal, and should be removed.
Manual cpuset configuration is also quite uncommon and not really something
worth exposing in the UI. It can easily be done from the command line
with virt-xml.
If people complain, I'd consider adding a checkbox for vcpu placement=auto,
or an option to do that by default for new VMs.
This is a little low level and rarely used IMO to have it in the UI.
If people want to edit this we should point them at virt-xml which
seems like the appropriate user friendlyness for this feature.
It's not consistently applied. If I had a setup to test against old xen
that still listed dom0, I'd make it so we never even show dom0 so we
can sidestep the problem entirely.
This has been supported for a long time now, and is more tested these
days, so let's use it rather than the old style AttachDevice method
It also works around a libvirt issue described in bz 1229819
memory doesn't have a separate input/output stats, so we shouldn't use
the in_out_vector_helper. This resulted in shutoff VMs appearing to still
use memory in the manager window.
It's largely the same, but now
- The code is better organized
- The UI is much more streamlined, only showing relevant fields when
required.
- We warn about the hostname/URI cases that we know libvirt will error on
- Drop some of the attempts at being smart, and just mimic what libvirt
will do.
Leaving a VM defined on the source is dangerous: if they are sharing
storage, and aren't using virtlockd, then they might be inadvertently
started in two places at once and trash a disk image.
Some people might still need the option to turn this off, so maybe we
will revive it. Not sure though
This is only needed when people have very specific downtime constraints
on public facing services. I don't think that covers many virt-manager
users. So suggest they just use the command line for this.
All major drivers either support it, or don't support save at all,
so I think we can safely drop it. If people still need it they can
get by with virsh.
qemu has provided this feature for a long time, and every other driver
we care about provides a reboot implementation as well, so drop our
handling of it.
There's no external callers anymore, and the prospect of keeping this
stuff cached but potentially having a thread invalidate it makes me nervous,
so simplify things by making callers explicitly request the object they
want to redefine.
Have libvirtobjects advertise a routine specifically for initial setup,
and emit a signal when it's complete. Then dispatch the associated conn
signal on demand as the objects are initialized. This should avoid a
whole class of ordering issues, and is easier to follow IMO.
People should rarely need to edit the mac address, so remove it from
the create wizard. However we only allow editing the mac address in
the 'customize' dialog: regular network details disables editing, since
that should be a rare and potentially dangerous operation.
