We need to tweak refresh() handling to work similar to the shared
XML and status caching in libvirtobject.py: when the user manually
invokes the refresh() operation, and storage events are set up,
we just invoke the refresh() but let the event loop handle
refreshing the cache.
This fixes a backtrace when invoking a manual refresh via the
host details dialog
When new pool objects appear, we call refresh() on them, to ensure
we have the latest data (in case manual changes were made to the
storage pool directory behind libvirt's back, which is quite common).
However with the storage event support, this results in lots of
REFRESHED signals during initial connection startup, which kick
off redundant object polling.
Avoid storage REFRESHED events if they come in before the connection
is finished starting up to skip this redundant polling.
Otherwise this triggers some event calls and results in double
polling during connection startup. Doesn't cause any issues, just
spams the logs and needless libvirt calls
Even if it's not marked readonly or shareable, floppy media is
very likely to be a shared resource and not something that belongs
to the VM that the user will want to delete by default.
If this flag is specified, --import|--boot will create a transient
libvirt domain, ie. one which goes away when the guest shuts down or
the host is rebooted.
(crobinso: some tweaks and tests)
It's been around for seven years, and even RHEL5 has it... I don't think
we need to work around platforms that don't have support for it.
Use this as an opportunity to simplify the surrounding code
continue_install is intended to facilitate windows XP style 3 stage
installs:
stage 1: initial dos style disk setup, reboot
stage 2: actual full installer, reboot
stage 3: OS is functional, virt-install is done
The code assumed that we needed to keep the cdrom as the primary
boot device for the second stage, so virt-install/virt-manager needed
to hang around through the second stage run, wait until the VM shutdown,
then encode the final XML to boot of the disk.
Windows is and always has been smart enough to handle that case though...
after the initial boot, if we set the hd as the primary boot device
for stage 2, the disk bits that windows already installed will make
use of the cdrom as necessary. So the entire premise of continue_install
is irrelevant. Maybe back when it was added, when xen didn't even have
working ACPI support, this served a purpose, but I'm pretty sure we
can safely drop it nowadays.
If the first install attempt fails, then the second attempt succeeds,
we were still removing the disk images we created as though the
install never succeeded. We need to clear out the cached failed_guest
value via the customize dialog callback
https://bugzilla.redhat.com/show_bug.cgi?id=1342043
Current libosinfo release on fedora23 and centos7
didn't know fedora23.
Change --os-variant fedora22 as a workaroud.
df1c3e74a introduce this issue.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
This is required in order to ask for correct domcapabilities. If you don't
specify any machine libvirt will return domcapabilities for default machine
which is xenpv.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This improves loading domcapabilities to get domcapabilities for recommended
machine, not for default machine.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There want be 1.3.6 version, libvirt switched to new release numbering, for more
information see <http://libvirt.org/downloads.html#numbering>.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This adds support for setting VirtualDisk <seclabel> XML. This
invents a new command line scheme for cases like this where there
are possibly multiple child elements that we want to specify
on the command line. So if you just want to specify one <seclabel>
block, you can do the expected
--disk ...,seclabel.model=dac,relabel=no
However if you want to specify 2 <seclabel> blocks you need to do:
--disk ...,seclabel0.model=dac,seclabel0.relabel=no,seclabel1.model=selinux,seclabel1.relabel=no
We register the VirtCLIArgument classes with the static parse
instructions, but instantiate it with the actual key=val pair
from the command line. This fixes some layering violations, and
gives callers access to the actual command line key that we
are parsing, if that's interesting.
Only initialize VirtCLIParser at actual parse time. The data that's
passed to __init__ is the particular data for that parse task, like
the option string, and the Guest object we are editing.
As a result we can drop the whole parsermap handling, since the
parserlist is immutable.
There's a bunch of other reworks mixed in like dropping the
VirtOptionString abstraction...
The VirtCLIArguments, (for example, path=, size=, etc. for --disk)
are only registered when a VirtCLIParser is actually initialized.
This seems backwards, since those arguments are really more immutable
factors of the actual command line parsing, so make more sense only
initializing them once, at class definition time.
This switches to use that pattern. This makes the parsing flow a bit
cleaner and can be a basis for future improvements.
Cole Robinson