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.
Right now we aren't showing the defaults like disk buses, sound devices,
disk cache modes, etc. This is confusing to the user and not that useful.
Encode the defaults before launching the wizard, so the user can see what
the end config will actually look like.
This might cause weirdness if going back to the create.py wizard, but
we'll see if anyone complains before handling that.
Not passing an emulator is only for showing ideal defaults in the UI.
When doing internal checks, we only want to disable features if we know
the emulator doesn't support them.
It is added only in the details window, and intentionally not added to
the addhardware UI to keep it simpler. Users can edit this after a
new device is added.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
I've noticed twice today that 'guestcpus' was set to 0 while the
domain was shutting down. Play safe and check that 'guestcpus' is > 0
before divide by it.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
(1) A separate nvram (ie. variable store) file for the domain exists if
and only if the following condition holds:
(self.get_xmlobj().os.loader_ro is True and
self.get_xmlobj().os.loader_type == "pflash")
(Refer to libvirtd's qemuPrepareNVRAM() function, as of commit 742b08e30.)
(2) The
self.get_xmlobj().os.nvram
condition is sufficient, but not necessary, for the separate varstore file
to exist. That is, if the condition holds, then the separate varstore file
exists for sure, but if the condition doesn't hold, the file may exist
nonetheless. (Because libvirtd can auto-generate the varstore file's
pathname.)
This means that requiring condition (2) for setting UNDEFINE_NVRAM on
domain deletion will miss a subset of the cases, ie. when the necessary
and sufficient condition (1) holds, but the sufficient-only condition (2)
doesn't.
Make sure that the code uses the necessary and sufficient condition (1).
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Rework things a bit to simplify everything we pass around.
The specific bug fix is making sure we update the object list in place,
otherwise the event loop detects it as the VM being deleted and closes
the details window.
We expose a simple combobox with two entries: BIOS, and UEFI. The
UEFI option is only selectable if 1) libvirt supports the necessary
domcapabilities bits, 2) it detects that qemu supports the necessary
command line options, and 3) libvirt detects a UEFI binary on the
host that maps to a known template via qemu.conf
If those conditions aren't met, we disable the UEFI option, and show
a small warning icon with an explanatory tooltip.
The option can only be changed via New VM->Customize Before Install.
For existing x86 VMs, it's a readonly label.
We would unconditionally read VM description/hotplug from the inactive
domain XML, this allowed us to emulate metadata hotplug where it wasn't
implemented. However this means we end up doing many needless XMLDesc
calls, which slows down connection startup for low latency connections.
Since SetMetadata has been in libvirt for 2 years now, drop this hack.
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.
Rather than register a bunch of functions to call, lump it all into
one function per page. This allows us to easily call UpdateDevice
unconditionally, to pick up any addition hotplug operations that
become available via libvirt and qemu.
Libvirt not allowed uid/gid_start
configured as none 0 or not specified.
This patch will disable config uid/gid_start in UI.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
When events were successfully registered, we skip the VM listing on
every tick, and instead trigger a manual refresh whenever a VM event
is received. Not as efficient as it should be, but saves us a lot of
API calls.
We acted like it would migrate a shutoff VM, but it just toggled
the LIVE flag. We should support true 'offline' migration, but
the UI will be different.
Racey shutdown can mean we try to poll disk stats at a time when
it won't work. Resetting the lists give things a chance to work
correctly when the VM is rebooted.
- Add options in the model drop down for clear, hvdefault, and app default
- Make 'copy host' a check box, when enabled it hides the model dropdown
- Detect if the VM CPU is a copy of the host CPU
- Undocumented bit that allows passing in host-model/host-passthrough
to the model field for people that really want those settings.
