And not the other way around. It's less confusing this way IMO, particularly
if virtio is selected by default and the user is confused, wondering
where the cdrom option is.
Take the opportunity to actually share the bus combo logic between details
and addhardware
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.
Previously we made all the default encoding non-permanent by XML objects
before generating the XML, making changes to the copies, and restoring
to the old state after the XML is returned to the user.
This allows us to call start_install multiple times with the same Guest
object and not alter it's original config... but that feature isn't really
useful anymore, and this behavior makes the 'customize before install'
dialog difficult to handle.
So drop most of it, and fix some of the minor fallout.
It's really a useless hold over from the days when we manually talked
to HAL.
One semi useful bit lost in the shuffle is the option to repoll cdroms
for media. But since virt-manager allows attaching a device to the
VM regardless of whether it notices media change, this plumbing is
really overkill. If libvirt ever grows nodedev events we will get this
much easier.
Takes a comma separated list of HVs, and only shows those as options in
the 'Open Connection' wizard. This option can be used to hide the bhyve
option as well, so drop --with-bhyve
No one uses it, and it can be handled easy enough with a wrapper script or
similar.
Message-Id: <1b33f161591b86407f78fb307aa4f89f6eee9e4e.1428346382.git.crobinso@redhat.com>
It's out of date, and doesn't even seem to work with current RHEL versions
and no one is complaining.
If we want to add it back, it should be an explicit setup.py configure
option.
It's very difficult to tell what bits of Viewer that vmmConsolePages
accesses, and what bits of vmmConsolePages that vmmDetails will access.
Clean up the Viewer side with consistent function names, lots of comments,
and privatizing everything that shouldn't be shared.
Yeah this is a big ugly commit...
These only work for xen x86, and are less relevant nowadays since HW
virt has been around for a very long time. Also it's tough to be sure
that we aren't giving a bogus warning.
Cole Robinson