We don't use this method of reloading rules anymore, so we can just
kill the code.
This simplifies things a lot because we no longer need to keep a
table of the rules we've added.
* src/util/iptables.c: kill iptablesReloadRules()
Long ago we tried to use Fedora's lokkit utility in order to register
our iptables rules so that 'service iptables restart' would
automatically load our rules.
There was one fatal flaw - if the user had configured iptables without
lokkit, then we would clobber that configuration by running lokkit.
We quickly disabled lokkit support, but never removed it. Let's do
that now.
The 'my virtual network stops working when I restart iptables' still
remains. For all the background on this saga, see:
https://bugzilla.redhat.com/227011
* src/util/iptables.c: remove lokkit support
* configure.in: remove --enable-lokkit
* libvirt.spec.in: remove the dirs used only for saving rules for lokkit
* src/Makefile.am: ditto
* src/libvirt_private.syms, src/network/bridge_driver.c,
src/util/iptables.h: remove references to iptablesSaveRules
This is the expected behaviour, I think - reloading libvirtd should
be a subset of restarting it.
Note, we reload the rules after we've determined which networks
are active (because we only add the rules for active networks)
and before we start autostart networks (to avoid re-adding the
rules).
* src/network/bridge_driver.c: reload iptables rules on startup
Currently, when we add iptables rules, we keep them on a list so that
we can easily reload them on e.g. 'service libvirtd reload'.
However, we don't save this list to disk, so if libvirtd is restarted
we lose the ability to reload the rules.
The fix is simple - just re-add the damn things on reload.
Note, we delete the rules before re-adding them, just like the current
behaviour of iptRulesReload().
* src/network/bridge_driver.c: re-add the iptables rules on reload.
There's a long known issue where if you install libvirt in a guest,
the default virtual network will conflict with the default virtual
network in the host.
That's one of the reasons we have the libvirt-client RPM - it allows
you to install the client library without having the host side
installed.
Rich Jones points out that if you install libvirt-devel in a guest,
then you get libvirtd installed and the network conflict:
https://bugzilla.redhat.com/531200
libvirt-devel should only require libvirt-client - e.g. nothing in
the devel package pertains to anything in the libvirt RPM. The Fedora
packaging guidelines say:
https://fedoraproject.org/wiki/Packaging/Guidelines#Devel_Packages
Devel packages must require the base package using a fully versioned
dependency ...
But for all intents and purposes, libvirt-client is our base RPM.
* libvirt.spec.in: make libvirt-devel require libvirt-client
If the the qemu and kvm binaries are the same, we don't include machine
types in the kvm domain info.
However, the code which refreshes the machine types info from the
previous capabilities structure first looks at the kvm domain's info,
finds it matches and then copies the empty machine types list over
for the top-level qemu domain.
That doesn't make sense, we shouldn't copy an empty machin types list.
* src/qemu/qemu_conf.c: qemudGetOldMachinesFromInfo(): don't copy an
empty machine types list.
If one has e.g.
<guest>
<os_type>hvm</os_type>
<arch name='x86_64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<machine>pc-0.11</machine>
<machine canonical='pc-0.11'>pc</machine>
<machine>pc-0.10</machine>
<machine>isapc</machine>
<domain type='qemu'>
</domain>
<domain type='kvm'>
<emulator>/usr/bin/kvm</emulator>
<machine>pc</machine>
<machine>isapc</machine>
</domain>
</arch>
</guest>
and start a guest with:
<domain type='kvm'>
...
<os>
<type arch='x86_64'>hvm</type>
...
</os>
</domain>
then the default machine type should be 'pc' and not 'pc-0.11'
Issue was reported by Anton Protopopov.
* src/capabilities.[ch]: pass the domain type to
virCapabilitiesDefaultGuestArch() and use it to look up the default
machine type from a specific guest domain if needed.
* src/conf/domain_conf.c, src/xen/xm_internal.c: update
* tests/qemuxml2argvdata/qemuxml2argv-machine-aliases2.xml: update
the domain type to 'kvm' and remove the machine type to check
that the default gets looked up correctly
The domain/os/type element may have an arch specified without having
a machine variant specified. In fact, this is what python-virtinst
does when defining a guest.
* docs/schemas/domain.rng: allow missing machine type
Otherwise logrotate barfs:
error: error accessing /var/log/libvirt/uml: No such file or directory
error: libvirtd:1 glob failed for /var/log/libvirt/uml/*.log
error: found error in /var/log/libvirt/qemu/*.log /var/log/libvirt/uml/*.log /var/log/libvirt/lxc/*.log , skipping
* qemud/Makefile.am: always create /var/log/libvirt/{lxc,uml} when
installing the logrotate conf; not ideal, but easier than making
the logrotate conf depend on which drivers are enabled
A simple misplaced break out of a switch results in:
libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./vendor': No such file or directory
libvir: error : Failed to open file '/sys/bus/pci/devices/0000:00:54c./device': No such file or directory
libvir: error : this function is not supported by the hypervisor: Failed to read product/vendor ID for 0000:00:54c.
when trying to passthrough a USB host device to qemu.
* src/security_selinux.c: fix a switch/break thinko
Use virStorageFileGetMetadata() to find any backing stores for images
and re-label them
Without this, qemu cannot access qcow2 backing files, see:
https://bugzilla.redhat.com/497131
* src/security/security_selinux.c: re-label backing store files in
SELinuxSetSecurityImageLabel()
Finally, we get to the point of all this.
Move virStorageGetMetadataFromFD() to virStorageFileGetMetadataFromFD()
and move to src/util/storage_file.[ch]
There's no functional changes in this patch, just code movement
* src/storage/storage_backend_fs.c: move code from here ...
* src/util/storage_file.[ch]: ... to here
* src/libvirt_private.syms: export virStorageFileGetMetadataFromFD()
Introduce a metadata structure and make virStorageGetMetadataFromFD()
fill it in.
* src/util/storage_file.h: add virStorageFileMetadata
* src/backend/storage_backend_fs.c: virStorageGetMetadataFromFD() now
fills in the virStorageFileMetadata structure
Prepare the code probing a file's format and associated metadata for
moving into libvirt_util.
* src/storage/storage_backend_fs.c: re-factor the format and metadata
probing code in preparation for moving it
Rename virStorageVolFormatFileSystem to virStorageFileFormat and
move to src/util/storage_file.[ch]
* src/Makefile.am: add src/util/storage_file.[ch]
* src/conf/storage_conf.[ch]: move enum from here ...
* src/util/storage_file.[ch]: .. to here
* src/libvirt_private.syms: update To/FromString exports
* src/storage/storage_backend.c, src/storage/storage_backend_fs.c,
src/vbox/vbox_tmpl.c: update for above changes
When we hot-unplug the last device, we're currently double-freeing
the device definition.
Reported by Martin Banas here:
https://bugzilla.redhat.com/523953
* src/qemu_driver.c: fix double free
* tests/testutilsqemu.c: add a machine types list for /usr/bin/kvm
which doesn't have any aliases, while the guest has aliases
* tests/qemuxml2argvdata/qemuxml2argv-machine-aliases2.*,
tests/qemuxml2argvtest.c: add a test using /usr/bin/kvm and make
sure that 'pc' machine type doesn't get canonicalized using the
aliases in the guest machine type list
The algorithm is quite simple:
If the emulator matches a guest's domain:
if domain has machine type info:
check the domain's machine type info
else
check the guest's default machine type info
else if the emulator matches the guest's default emulator:
check the guest's default machine type info
The previous implementation was incorrectly falling back to the default
machine type info if the domain's machine type info didn't have an
alias.
* src/qemu_driver.c: simplify and fix qemudCanonicalizeMachine()
Currently we only probe the main qemu binary for machine types, but we
should also probe the kvm binary.
* src/qemu_conf.c: probe kvm binary machines in qemudCapsInitGuest()
We need to look at all the domain infos in guest capabilities, not
just the defaults.
In order to allow that, split out a qemudGetOldMachinesFromInfo()
from qemudGetOldMachines(). We'll make more use of it in the next
patch.
* src/qemu_conf.c: split out qemudGetOldMachinesFromInfo() from
qemudGetOldMachines()
* tests/testutilsqemu.c: make 'pc' an alias for qemu-system-x86_64
* tests/qemuxml2argvdata/qemuxml2argv-machine-aliases1.*,
tests/qemuxml2argvtest.c: add a test which uses qemu-system-x86_64
and make sure the machine type is canonicalized.
This doesn't have any affect on the current tests because we don't have
any machine aliases in the current test data.
* src/qemu_conf.h, src/qemu_driver.c: expose qemudCanonicalizeMachine()
for the tests
* tests/qemuxml2argvtest.c: canonicalize the machine type
Things added include
- x86_64 host
- Migration features
- NUMA topology
- Security model
- Canonical machine types
- Domain machine types
- An arm guest
- More machine types for mips, mipsel, sparc and ppc
- An x86_64 xenner guest
This file was generated on a Fedora 12 machine using latest libvirt
and qemu-kvm-0.11.0-rc2
* tests/capabilityschemadata/caps-qemu-kvm.xml: add more features
to test
https://bugzilla.redhat.com/517371
Matt Booth points out that if you use a non-existent bridge name when
start a guest you get a weird error message:
Failed to add tap interface 'vnet%d' to bridge 'virbr0'
and dev='vnet%d' appears in the dumpxml output.
Fix that by not including 'vnet%d' in the error message and freeing the
'vnet%d' string if adding the tap device to the bridge fails.
* src/qemu_conf.c, src/uml_conf.c: fix qemudNetworkIfaceConnect()
and umlConnectTapDevice() to not expose 'vnet%d' to the user
As we start/shutdown guests, or hotplug/hot-unplug devices, we can add
or delete devices as appropriate from a list of active devices.
Then, in pciReset(), we can use this to determine whether its safe to
reset a device as a side effect of resetting another device.
* src/qemu_conf.h: add activePciHostdevs to qemud_driver
* src/qemu_driver.c: maintain the activePciHostdevs list, and pass it
to pciResetDevice()
* src/pci.[ch]: pass the activeDevs list to pciResetDevice() and use
it to determine whether a Secondary Bus Reset is safe
The qemuPrepareHostDevices() and qemuDomainReAttachHostDevices()
functions are clutter with a bunch of calls to pciGetDevice() and
pciFreeDevice() obscuring the basic logic.
Add a pciDeviceList type and add a qemuGetPciHostDeviceList() function
to build a list from a domain definition. Use this in prepare/re-attach
fto simplify things and eliminate the multiple pciGetDevice calls.
This is especially useful because in the next patch we need to iterate
the hostdevs list a third time and we also need a list type for keeping
track of active devices.
* src/pci.[ch]: add pciDeviceList type and also a per-device 'managed'
property
* src/libvirt_private.syms: export the new functions
* src/qemu_driver.c: add qemuGetPciHostDeviceList() and re-write
qemuPrepareHostDevices() and qemuDomainReAttachHostDevices() to use it
Newer versions of QEMU accept 'pci_add auto', but older versions require
'pci_add pci_addr=auto'
* src/qemu_driver.c: use pci_addr= in qemudDomainAttachHostPciDevice()
for older versions of QEMU
When we hot-unplug a PCI host device from a guest, we should reset it.
Both managed and unmanaged devices should be reset, but only managed
devices should be re-attached.
* src/qemu_driver.c: reset devices in qemudDomainDetachHostPciDevice()
Right now we're only resetting managed devices before hotplug, but we
should reset them irrespective of whether they are managed.
* src/qemu_driver.c: reset all PCI hostdevs before hotplug
It turns out that the previous attempt at this doesn't work well
in the case of hotplug. We need qemuCheckPciHostDevice() to
disallow the reset affecting devices already attach to the guest,
but we still need to avoid double locking the virDomainObjPtr.
This is all getting messy, I've a better idea.
This reverts commit 6318808270 and
c106c8a18c.
* src/qemu_driver.c, src/pci.[ch], src/xen_unified.c,
src/libvirt_private.syms: revert a bunch of stuff.
The current code makes a poor effort at updating the device arrays after
hot-unplug. Fix that and combine the two code paths into one.
* src/qemu_driver.c: fix list updating in qemudDomainDetachNetDevice(),
qemudDomainDetachPciDiskDevice() and qemudDomainDetachHostPciDevice()
Maybe it's just me, but I try to select an item from the tree using
double-click and get annoyed when "+-" gets included in the selection.
* src/virsh.c: add a space between "+-" and the node device name
in 'virsh nodedev-list --tree'
If a PCI device reset causes other devices to be reset, allow it so long
as those other devices are note assigned to another active domain.
Note, we need to take the driver lock qemudNodeDeviceReset() because the
check function will iterate over the domain list.
* src/qemu_conf.c: add qemuCheckPciHostDevice() to iterate over active
domains checking whether the affected device is assigned
* src/pci.[ch]: add pciDeviceEquals() helper
When using a Secondary Bus Reset, all devices on the bus are reset.
Extend the pciResetDevice() API so that a 'check' callback can be
supplied which will verify that it is safe to reset the other devices
on the bus.
The virDomainObjPtr parameter is needed so that when the check function
iterates over the domain list, it can avoid double locking.
* src/pci.[ch]: add a 'check' callback to pciResetDevice(), re-work
pciIterDevices() to pass the check function to the iter functions,
use the check function in the bus iterator, return the first unsafe
device from pciBusCheckOtherDevices() and include its details in
the bus reset error message.
* src/qemu_driver.c, src/xen_uninified.c: just pass NULL as the
check function for now
Currently, if we are unable to reset a PCI device we return a fairly
generic 'No PCI reset capability available' error message.
Fix that by returning an error from the individual reset messages and
using that error to construct the higher level error mesage.
* src/pci.c: set errors in pciTryPowerManagementReset() and
pciTrySecondaryBusReset() on failure; use those error messages
in pciResetDevice(), or explain that no reset support is available
When the guest shuts down, we should attempt to restore all PCI host
devices to a sane state.
In the case of managed hostdevs, we should reset and re-attach the
devices. In the case of unmanaged hostdevs, we should just reset them.
Note, KVM will already reset assigned devices when the guest shuts
down using whatever means it can, so we are only doing it to cover the
cases the kernel can't handle.
* src/qemu_driver.c: add qemuDomainReAttachHostDevices() and call
it from qemudShutdownVMDaemon()
It turns out that a PCI Power Management reset only affects individual
functions, and not the whole device.
The PCI Power Management spec talks about resetting the 'device' rather
than the 'function', but Intel's Dexuan Cui informs me that it is
actually a per-function reset.
Also, Yu Zhao has added pci_pm_reset() to the kernel, and it doesn't
reject multi-function devices, so it must be true! :-)
(A side issue is that we could defer the PM reset to the kernel if we
could detect that the kernel has PM reset support, but barring version
number checks we don't have a way to detect that support)
* src/pci.c: remove the pciDeviceContainsOtherFunctions() check from
pciTryPowerManagementReset() and prefer PM reset over bus reset
where both are available
Cc: Cui, Dexuan <dexuan.cui@intel.com>
Cc: Yu Zhao <yu.zhao@intel.com>
PCI device assignment is only supported in KVM's fork of qemu, so we
should really detect its availability and give a nice error if its
not supported.
* src/qemu_conf.[ch]: introduce QEMUD_CMD_FLAG_PCIDEVICE indicating
that the -pcidevice command line option is available
* tests/*: update the tests
Attaching a host PCI device to a qemu guest is done with a
straightforward 'pci_add auto host host=XX:XX.X' command.
Like with NIC and disk hotplug, we need to retain the guest PCI address
assigned by qemu so that we can use it for hot-unplug.
Identifying a device for detach is done using the host PCI address.
Managed mode is handled by detaching/resetting the device before
attaching it to the guest and re-attaching it after detaching it from
the guest.
* src/qemu_driver.c: add qemudDomainAttachHostPciDevice() and
qemudDomainDetachHostPciDevice()
* src/domain_conf.h: add somewhere to store the guest PCI address
* src/domain_conf.c: handle formatting and parsing the guest PCI
address
Re-factor the hostdev hotplug code so that we can easily add PCI
hostdev hotplug to qemudDomainAttachHostDevice().
* src/qemu_driver.c: rename qemudDomainAttachHostDevice() to
qemudDomainAttachHostUsbDevice(); make qemudDomainAttachHostDevice()
handle all hostdev types
* src/libvirt_private.syms: export a couple of hostdev related
ToString() functions
If the ipv6 kernel module is not loaded, then we get this when starting
a virtual network:
libvir: Network Config error :
cannot enable /proc/sys/net/ipv6/conf/virbr0/disable_ipv6:
No such file or directory
If disable_ipv6 is not present, we should just merrily continue on our
way.
* src/network_driver.c: make networkDisableIPV6() not fail if the kernel
has no ipv6 support
Allow qemu user to open kernel/initrds in this dir, but still prevent
others from listing it.
* libvirt.spec.in: set /var/lib/libvirt/boot perms to 0711
If we're running qemu unprivileged, we need to chown any supplied kernel
or initrd before spawning it.
* src/qemu_driver.c: rename qemuDomainSetDiskOwnership() to
qemuDomainSetFileOwnership(), pass it a path string instead of a disk
definition and use it for chowning the kernel/initrd in
qemuDomainSetAllDeviceOwnership()
PCIe DevCap register is actually 32 bits, not 16 bits. Since FLR is
bit 28, we clearly are failing to detect FLR support.
Known to fix device reset with some SR-IOV devices.
* src/pci.c: fix pciDetectFunctionLevelReset()
polkit was disabled by default for a reason - because we selectively
enable it on newer fedoras rather than disable it on older fedoras
Same fix needed for netcf
It's not needed at build time
Removed in Fedora by:
* Fri Jun 5 2009 Mark McLoughlin <markmc@redhat.com> - 0.6.4-2.fc12
- Remove the qemu BuildRequires
Disabled on < f12 for now until netcf is in Fedora updates
BuildRequires netcf if enabled, pass --without-netcf if its disabled
* libvirt.spec.in: enabled netcf by default
In order to hotplug a network/bridge backed NIC, we need to first create
the tap file descriptor, add the tap interface to the bridge and then
pass the file descriptor to the qemu process using the 'getfd' monitor
command.
Once the tapfd has been accepted, we create the network backend using
host_net_add, supplying the name assigned to the tapfd. If this fails,
we need to close the tapfd in qemu using the 'closefd' monitor command.
If the version of qemu does not support the getfd/closefd monitor
commands we detect "unknown command" in the getfd reply and fail the
attach operation.
* src/qemu_driver.c: add support for tapfd based hotplug in
qemudDomainAttachNetDevice()
Add qemudMonitorCommandWithFd() which allows a file descriptor to be
sent to qemu over a unix monitor socket using SCM_RIGHTS. See the
unix(7) and cmsg(3) man pages.
* src/qemu_conf.c: add a scm_fd param to qemudMonitorCommandExtra(),
add qemudMonitorCommandWithFd(), implement SCM_RIGHTS support in
qemudMonitorSendUnix()
Switch from using write() to using sendmsg() on QEMU's monitor socket
so that we can add support for SCM_RIGHTS.
* src/qemu_driver.c: add sendmsg() based qemudMonitorSendUnix() and use
it when the monitor fd is a unix socket
Add a little helper function to write the monitor command followed by
carriage return in a single write.
This doesn't make any real difference, but allows us to more easily
switch to using sendmsg() when using the monitor over a unix socket.
* src/qemu_conf.c: split qemudMonitorSend() out
In subsequent patches we're going to have a file descriptor to close
too, so centralize the error handling cleanups to make things easier.
* src/qemu_conf.c: in qemudDomainAttachNetDevice() consolidate the
error handling cleanups together
With hotplug, we're going to want to pass a tapfd name rather than an
actual file descriptor, so prepare the way by passing a string tapfd to
qemuBuildHostNetStr().
* src/qemu_conf.h: qemuBuildHostNetStr() takes a string tapfd now
* src/qemu_conf.c: pass qemuBuildHostNetStr() a string rather than an
actual file descriptor
* src/qemu_driver.c: update qemudDomainAttachNetDevice() for change
* src/qemu_conf.h: export qemudNetworkIfaceConnect()
* src/qemu_conf.c: move vnet_hdr logic into qemudNetworkIfaceConnect()
since we need it for hotplug too
By probing for qemu machine types, we increased the time of a
GetCapabilities call from 100us to a whopping 60ms.
This patch takes the approach of only probing for machine types
when the mtime of the emulator binary changed since the last time
the capabilities were generated.
* src/capabilities.h: cache the emulator binary mtime
* src/qemu_conf.c: add qemudGetOldMachines() to copy the machine
types from the old caps struct if the mtime for the binary hasn't
changed
* src/qemu_conf.h, src/qemu_driver.c: pass the old caps pointer to
qemudCapsInit()
e.g. <machine canonical='pc'>pc-0.11</machine>
* src/capabilities.c: output the canonical machine names in the
capabilities output, if available
* docs/schemas/capabilities.rng: add the new attribute
Not all possible emulators are actually in the capabilities, so if we
don't find the supplied emulator we should probe it directly for machine
types.
* src/qemu_driver.c: add qemudCanonicalizeMachineDirect() to directly
probe an emulator for the canonical machine type
In qemu-0.11 there is a 'pc-0.10' machine type which allows you to run
guests with a machine which is compatible with the pc machine in
qemu-0.10 - e.g. using the original PCI class for virtio-blk and
virtio-console and disabling MSI support in virtio-net. The idea here
is that we don't want to suprise guests by changing the hardware when
qemu is updated.
I've just posted some patches for qemu-0.11 which allows libvirt to
canonicalize the 'pc' machine alias to the latest machine version.
This patches makes us use that so that when a guest is configured to
use the 'pc' machine type, we resolve that to 'pc-0.11' machine and
save that in the guest XML.
See also:
https://fedoraproject.org/wiki/Features/KVM_Stable_Guest_ABI
* src/qemu_conf.c: add qemudCanonicalizeMachine() to canonicalize
the machine type according to the machine aliases in capabilities
* src/qemu_driver.c: parse aliases in qemudParseMachineTypesStr()
A subsequent commit will add a "canonical" field to this structure,
this patch basically just prepares the way for that.
The new type is added, along with virCapabilitiesAlloc/FreeMachines()
helpers and a whole bunch of code to make the transition.
One quirk is that virCapabilitiesAddGuestDomain() and
virCapabilitiesAddGuest() take ownership of the machine list rather
than duping it. This makes sense to avoid needless copying.
* src/capabilities.h: add the virCapsGuestMachine struct and use it
in virCapsGuestDomainInfo, add prototypes for new functions and
update the AddGuest() prototypes
* src/capabilities.c: add code for allocating and freeing the new
type, change the machines parameter to AddGuest() etc.
* src/libvirt_private.syms: export the new helpers
* src/qemu_conf.c: update all the machine type code to use the new
struct
* src/xen_internal.c: ditto
* tests/testutilsqemu.c: ditto
Currently we hardcode the QEMU machine types. We should really just
parse the output of 'qemu -M ?' so the lists don't get out of sync.
xenner doesn't support '-M ?', so we still need to hardcode that.
The horrible (const char *const *) is removed in a subsequent patch.
* src/qemu_conf.c: kill the arch_info*machines tables, retain the
hardcoded xenner machine type, add qemudProbeMachineTypes() to
run and parse 'qemu -M ?' and use it in qemudCapsInitGuest()
There's no need for the hasbase/hasaltbase confusion, just store the
first binary path found in a variable.
* src/qemu_conf.c: kill hasbase/hasaltbase logic in qemudCapsInitGuest()
qemu network devices are hot-unplugged in two stages - first the PCI NIC
is removed using 'pci_del <pci_addr>' and then the backend is removed
using 'host_net_remove <vlan> <name>'.
In order to perform these operations we need to have retained the
PCI address, backend name and vlan number.
* src/qemu_driver.c: add qemudDomainDetachNetDevice()
When we pci_add a NIC, we need to retain the PCI address assigned by
qemu for using during detach.
* src/qemu_driver.c: use qemudParsePciAddReply() to pull the PCI
address from the pci_add reply
* src/domain_conf.c: handle storing and parsing the PCI address in the
domain state XML file
The current code for parsing pci_add replies ignores the the domain and
bus numbers. Re-write the code to rectify that.
Also, since pci_add is used for NIC hotplug as well ask disk hotplug,
re-factor the code into a separate function.
* src/qemu_driver.c: add qemudParsePciAddReply() function which can
handle parsing domain and bus numbers
If we fail to pci_add a NIC, we should remove the network backend and
leave things the way we found them. To do that, we pre-allocate a
host_net_remove monitor command and issue that if the pci_add fails.
If the remove fails, we just log a warning.
We can only do this if we have a name for the network backend and
we know the vlan number its associated with.
* src/qemu_driver.c: host_net_remove the network backend if the
pci_add fails
Implement basic NIC hotplug support using the 'host_net_add' and
'pci_add' qemu monitor commands.
For now, we don't support 'bridge' or 'network' types.
Also, if pci_add fails, we currently fail to remove the backend
which we added.
Finally, NIC hot-unplug support is missing.
* src/qemu_driver.c: add qemudDomainAttachNetDevice()
* src/qemu_conf.[ch]: export qemuBuildNicStr(), qemuBuildHostNetStr()
and qemuAssignNames()
* src/libvirt_private.syms: export virDomainNetTypeToString()
qemudDomainChangeEjectableMedia() currently extracts the qemu command
line flags, but other device attaching code might need it, so move
the qemudExtractVersionInfo() call up a frame.
* src/qemu_driver.c: move the qemudExtractVersionInfo() call from
qemudDomainChangeEjectableMedia() to qemudDomainAttachDevice()
Mark McLoughlin