- 17 7月, 2012 1 次提交
-
-
由 Stefan Berger 提交于
Introduce new members in the virMacAddr 'class' - virMacAddrSet: set virMacAddr from a virMacAddr - virMacAddrSetRaw: setting virMacAddr from raw 6 byte MAC address buffer - virMacAddrGetRaw: writing virMacAddr into raw 6 byte MAC address buffer - virMacAddrCmp: comparing two virMacAddr - virMacAddrCmpRaw: comparing a virMacAddr with a raw 6 byte MAC address buffer then replace raw MAC addresses by replacing - 'unsigned char *' with virMacAddrPtr - 'unsigned char ... [VIR_MAC_BUFLEN]' with virMacAddr and introduce usage of above functions where necessary.
-
- 14 6月, 2012 1 次提交
-
-
由 Peter Krempa 提交于
Libvirt updates the configuration of SPICE server only when something changes. This is unfortunate when the user wants to disconnect a existing spice session when the connected attribute is already "disconnect". This patch modifies the conditions for calling the password updater to be called when nothing changes, but the connected attribute is already "disconnect".
-
- 23 5月, 2012 1 次提交
-
-
由 Peter Krempa 提交于
The pciDevice structure corresponding to the device being hot-unplugged was freed after it was "stolen" from activeList. The pointer was still used for eg-inactive list. This patch removes the free of the structure and frees it only if reset fails on the device.
-
- 17 5月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
If qemuPrepareHostdevUSBDevices fail it will roll back devices added to the driver list of used devices. However, if it may fail because the device is being used already. But then again - with roll back. Therefore don't try to remove a usb device manually if the function fail. Although, we want to remove the device if any operation performed afterwards fail.
-
- 11 5月, 2012 1 次提交
-
-
由 Guannan Ren 提交于
when failing to attach another usb device to a domain for some reason which has one use device attached before, the libvirtd crashed. The crash is caused by null-pointer dereference error in invoking usbDeviceListSteal passed in NULL value usb variable. commit 05abd150 introduces the bug.
-
- 07 5月, 2012 2 次提交
-
-
由 Guannan Ren 提交于
src/qemu/qemu_hostdev.c: refactor qemuPrepareHostdevUSBDevices function, make it focus on adding usb device to activeUsbHostdevs after check. After that, the usb hotplug function qemuDomainAttachHostDevice also could use it. expand qemuPrepareHostUSBDevices to perform the usb search, rollback on failure. src/qemu/qemu_hotplug.c: If there are multiple usb devices available with same vendorID and productID, but with different value of "bus, device", we give an error to let user use <address> to specify the desired one.
-
由 Guannan Ren 提交于
usbFindDevice():get usb device according to idVendor, idProduct, bus, device it is the exact match of the four parameters usbFindDeviceByBus():get usb device according to bus, device it returns only one usb device same as usbFindDevice usbFindDeviceByVendor():get usb device according to idVendor,idProduct it probably returns multiple usb devices. usbDeviceSearch(): a helper function to do the actual search
-
- 18 4月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Most of our errors complaining about an inability to support a particular action due to qemu limitations used CONFIG_UNSUPPORTED, but we had a few outliers. Reported by Jiri Denemark. * src/qemu/qemu_command.c (qemuBuildDriveDevStr): Prefer CONFIG_UNSUPPORTED. * src/qemu/qemu_driver.c (qemuDomainReboot) (qemuDomainBlockJobImpl): Likewise. * src/qemu/qemu_hotplug.c (qemuDomainAttachPciControllerDevice): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorTransaction) (qemuMonitorBlockJob, qemuMonitorSystemWakeup): Likewise.
-
- 03 4月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
Originally, qemuDomainCheckEjectableMedia was entering monitor with qemu driver lock. Commit 2067e31b, which I made to fix that, revealed another issue we had (but didn't notice it since the driver was locked): we didn't set nested job when qemuDomainCheckEjectableMedia is called during migration. Thus the original fix I made was wrong.
-
- 31 3月, 2012 1 次提交
-
-
由 Hendrik Schwartke 提交于
This patch was created to resolve this upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=784767 and is at least a partial solution to this RHEL RFE: https://bugzilla.redhat.com/show_bug.cgi?id=805071 Previously the only attribute of a network device that could be modified by virUpdateDeviceFlags() ("virsh update-device") was the link state; attempts to change any other attribute would log an error and fail. This patch adds recognition of a change in bridge device name, and supports reconnecting the guest's interface to the new device. Standard audit logs for detaching and attaching a network device are also generated. Although the current auditing function doesn't log the bridge being attached to, this will later be changed in a separate patch.
-
- 30 3月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
The code is splattered with a mix of sizeof foo sizeof (foo) sizeof(foo) Standardize on sizeof(foo) and add a syntax check rule to enforce it Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 27 3月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
This avoids possible deadlock of the qemu driver in case a domain is begin migrated (in Begin phase) and unrelated connection to qemu driver is closed at the right time. I checked all callers of qemuDomainCheckEjectableMedia() and they are calling this function with qemu driver locked.
-
- 16 3月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
This function potentially allocates new virCgroup but never frees it.
-
- 13 3月, 2012 1 次提交
-
-
由 Guannan Ren 提交于
In qemuDomainDetachNetDevice, detach was being used before it had been validated. If no matching device was found, this resulted in a dereference of a NULL pointer. This behavior was a regression introduced in commit cf90342b, so it has not been a part of any official libvirt release.
-
- 09 3月, 2012 2 次提交
-
-
由 Laine Stump 提交于
There are several functions in domain_conf.c that remove a device object from the domain's list of that object type, but don't free the object or return it to the caller to free. In many cases this isn't a problem because the caller already had a pointer to the object and frees it afterward, but in several cases the removed object was just left floating around with no references to it. In particular, the function qemuDomainDetachDeviceConfig() calls functions to locate and remove net (virDomainNetRemoveByMac), disk (virDomainDiskRemoveByName()), and lease (virDomainLeaseRemove()) devices, but neither it nor its caller qemuDomainModifyDeviceConfig() ever obtain a pointer to the device being removed, much less free it. This patch modifies the following "remove" functions to return a pointer to the device object being removed from the domain device arrays, to give the caller the option of freeing the device object using that pointer if needed. In places where the object was previously leaked, it is now freed: virDomainDiskRemove virDomainDiskRemoveByName virDomainNetRemove virDomainNetRemoveByMac virDomainHostdevRemove virDomainLeaseRemove virDomainLeaseRemoveAt The functions that had been leaking: libxlDomainDetachConfig - leaked a virDomainDiskDef qemuDomainDetachDeviceConfig - could leak a virDomainDiskDef, a virDomainNetDef, or a virDomainLeaseDef qemuDomainDetachLease - leaked a virDomainLeaseDef
-
由 Laine Stump 提交于
There were certain paths through the hostdev detach code that could lead to the lower level function failing (and not removing the object from the domain's hostdevs list), but the higher level function free'ing the hostdev object anyway. This would leave a stale hostdevdef pointer in the list, which would surely cause a problem eventually. This patch relocates virDomainHostdevRemove from the lower level functions qemuDomainDetachThisHostDevice and qemuDomainDetachHostPciDevice, to their caller qemuDomainDetachThisHostDevice, placing it just before the call to virDomainHostdevDefFree. This makes it easy to verify that either both operations are done, or neither. NB: The "dangling pointer" part of this problem was introduced in commit 13d5a6, so it is not present in libvirt versions prior to 0.9.9. Earlier versions would return failure in certain cases even though the the device object was removed/deleted, but the removal and deletion operations would always both happen or neither.
-
- 06 3月, 2012 8 次提交
-
-
由 Roopa Prabhu 提交于
These changes are applied only if the hostdev has a parent net device (i.e. if it was defined as "<interface type='hostdev'>" rather than just "<hostdev>"). If the parent netdevice has virtual port information, the original virtualport associate functions are called (these set and restore both mac and port profile on an interface). Otherwise, only mac address is set on the device. Note that This is only supported for SR-IOV Virtual Functions (not for standard PCI or USB netdevs), and virtualport association is only supported for 802.1Qbh. For all other types of cards and types of virtualport, a "Config Unsupported" error is returned and the operation fails. Signed-off-by: NRoopa Prabhu <roprabhu@cisco.com>
-
由 Laine Stump 提交于
qemuDomainAttachNetDevice - re-ordered some things at start of function because networkAllocateActualDevice should always be run and a slot in def->nets always allocated, but host_net_add isn't needed if the actual type is hostdev. - if actual type is hostdev, defer to qemuDomainAttachHostDevice (which will reach up to the NetDef for things like MAC address when necessary). After return from qemuDomainAttachHostDevice, slip directly to cleanup, since the rest of the function is specific to emulated net devices. - put assignment of new NetDef into expanded def->nets down below cleanup: (but only on success) since it is also needed for emulated and hostdev net devices. qemuDomainDetachHostDevice - after locating the exact device to detach, check if it's a network device and, if so, use toplevel qemuDomainDetachNetDevice instead so that the def->nets list is properly updated, and 'actual device' properly returned to network pool if appropriate. Otherwise, for normal hostdevs, call the lower level qemuDomainDetachThisDevice. qemuDomainDetachNetDevice - This is where it gets a bit tricky. After locating the device on the def->nets list, if the network device type == hostdev, call the *lower level* qemuDomainDetachThisDevice (which will reach back up to the parent net device for MAC address / virtualport when appropriate, then clear the device out of def->hostdevs) before skipping past all the emulated net-device-specific code to cleanup:, where the network device is removed from def->nets, and the network device object is freed. In short, any time a hostdev-type network device is detached, we must go through the toplevel virDomaineDetachNetDevice function first and last, to make sure 1) the def->nnets list is properly managed, and 2) any device allocated with networkAllocateActualDevice is properly freed. At the same time, in the middle we need to go through the lower-level vidDomainDetach*This*HostDevice to be sure that 1) the def->hostdevs list is properly managed, 2) the PCI device is properly detached from the guest and reattached to the host (if appropriate), and 3) any higher level teardown is called at the appropriate time, by reaching back up to the NetDef config (part (3) will be covered in a separate patch).
-
由 Laine Stump 提交于
The code being replaced is exactly identical to the newly global function, right down to the comment.
-
由 Laine Stump 提交于
This refactoring is necessary to support hotplug detach of type=hostdev network devices, but needs to be in a separate patch to make potential debugging of regressions more practical. Rather than the lowest level functions searching for a matching device, the search is now done in the toplevel function, and an intermediate-level function (qemuDomainDetachThisHostDevice()), which expects that the device's entry is already found, is called (this intermediate function will be called by qemuDomainDetachNetDevice() in order to support detach of type=hostdev net devices) This patch should result in 0 differences in functionality.
-
由 Laine Stump 提交于
Code movement only, no functional change. This is necessary to prevent a forward reference in an upcoming patch.
-
由 Laine Stump 提交于
In order to allow for a virDomainHostdevDef that uses the virDomainDeviceInfo of a "higher level" device (such as a virDomainNetDef), this patch changes the virDomainDeviceInfo in the HostdevDef into a virDomainDeviceInfoPtr. Rather than adding checks all over the code to check for a null info, we just guarantee that it is always valid. The new function virDomainHostdevDefAlloc() allocates a virDomainDeviceInfo and plugs it in, and virDomainHostdevDefFree() makes sure it is freed. There were 4 places allocating virDomainHostdevDefs, all of them parsers of one sort or another, and those have all had their VIR_ALLOC(hostdev) changed to virDomainHostdevDefAlloc(). Other than that, and the new functions, all the rest of the changes are just mechanical removals of "&" or changing "." to "->".
-
由 Laine Stump 提交于
There will be cases where the iterator callback will need to know the type of the device whose info is being operated on, and possibly even need to use some of the device's config. This patch adds a virDomainDeviceDefPtr to the args of every callback, and fills it in appropriately as the devices are iterated through.
-
由 Laine Stump 提交于
The virDomainDeviceInfoPtrs in qemuCollectPCIAddress and qemuComparePCIDevice are named "dev" and "dev1", but those functions will be changed (in order to match a change in the args sent to virDomainDeviceInfoIterate() callback args) to contain a virDomainDeviceDefPtr device. This patch renames "dev" to "info" (and "dev[n]" to "info[n]") to avoid later confusion.
-
- 28 2月, 2012 2 次提交
-
-
由 Osier Yang 提交于
For any disk controller model which is not "lsilogic", the command line will be like: -drive file=/dev/sda,if=none,id=drive-scsi0-0-3-0,format=raw \ -device scsi-disk,bus=scsi0.0,channel=0,scsi-id=3,lun=0,i\ drive=drive-scsi0-0-3-0,id=scsi0-0-3-0 The relationship between the libvirt address attrs and the qdev properties are (controller model is not "lsilogic"; strings inside <> represent libvirt adress attrs): bus=scsi<controller>.0 channel=<bus> scsi-id=<target> lun=<unit> * src/qemu/qemu_command.h: (New param "virDomainDefPtr def" for function qemuBuildDriveDevStr; new param "virDomainDefPtr vmdef" for function qemuAssignDeviceDiskAlias. Both for virDomainDiskFindControllerModel's use). * src/qemu/qemu_command.c: - New param "virDomainDefPtr def" for qemuAssignDeviceDiskAliasCustom. For virDomainDiskFindControllerModel's use, if the disk bus is "scsi" and the controller model is not "lsilogic", "target" is one part of the alias name. - According change on qemuAssignDeviceDiskAlias and qemuBuildDriveDevStr * src/qemu/qemu_hotplug.c: - Changes to be consistent with declarations of qemuAssignDeviceDiskAlias qemuBuildDriveDevStr, and qemuBuildControllerDevStr. * tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args, tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args: Update the generated command line.
-
由 Laine Stump 提交于
In qemuDomainAttachNetDevice, the guest's tap interface has only been attached to the bridge if iface_connected is true. It's possible for an error to occur prior to that happening, and previously we would attempt to remove the tap interface from the bridge even if it hadn't been attached.
-
- 16 2月, 2012 2 次提交
-
-
由 Ansis Atteka 提交于
This patch allows libvirt to add interfaces to already existing Open vSwitch bridges. The following syntax in domain XML file can be used: <interface type='bridge'> <mac address='52:54:00:d0:3f:f2'/> <source bridge='ovsbr'/> <virtualport type='openvswitch'> <parameters interfaceid='921a80cd-e6de-5a2e-db9c-ab27f15a6e1d'/> </virtualport> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> or if libvirt should auto-generate the interfaceid use following syntax: <interface type='bridge'> <mac address='52:54:00:d0:3f:f2'/> <source bridge='ovsbr'/> <virtualport type='openvswitch'> </virtualport> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> It is also possible to pass an optional profileid. To do that use following syntax: <interface type='bridge'> <source bridge='ovsbr'/> <mac address='00:55:1a:65:a2:8d'/> <virtualport type='openvswitch'> <parameters interfaceid='921a80cd-e6de-5a2e-db9c-ab27f15a6e1d' profileid='test-profile'/> </virtualport> </interface> To create Open vSwitch bridge install Open vSwitch and run the following command: ovs-vsctl add-br ovsbr
-
由 Laine Stump 提交于
An upcoming patch will add a <virtualport> element to interfaces of type='bridge', so it makes sense to give this function a more generic name.
-
- 27 1月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
QEMU always sends details about all available block devices as an answer for "info block"/"query-block" command. On the other hand, our qemuMonitorGetBlockInfo was made for a single block devices queries only. Thus, when asking for multiple devices, we asked qemu multiple times to always get the same answer from which different parts were filtered. This patch makes qemuMonitorGetBlockInfo return a hash table of all block devices, which may later be used for getting details about specific devices.
-
- 18 1月, 2012 1 次提交
-
-
由 Osier Yang 提交于
pciTrySecondaryBusReset checks if there is active device on the same bus, however, qemu driver doesn't maintain an effective list for the inactive devices, and it passes meaningless argument for parameter "inactiveDevs". e.g. (qemuPrepareHostdevPCIDevices) if (!(pcidevs = qemuGetPciHostDeviceList(hostdevs, nhostdevs))) return -1; ..skipped... if (pciResetDevice(dev, driver->activePciHostdevs, pcidevs) < 0) goto reattachdevs; NB, the "pcidevs" used above are extracted from domain def, and thus one won't be able to attach a device of which bus has other device even detached from host (nodedev-detach). To see more details of the problem: RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=773667 This patch is to resolve the problem by introducing an inactive PCI device list (just like qemu_driver->activePciHostdevs), and the whole logic is: * Add the device to inactive list during nodedev-dettach * Remove the device from inactive list during nodedev-reattach * Remove the device from inactive list during attach-device (for non-managed device) * Add the device to inactive list after detach-device, only if the device is not managed With the above, we have a sufficient inactive PCI device list, and thus we can use it for pciResetDevice. e.g.(qemuPrepareHostdevPCIDevices) if (pciResetDevice(dev, driver->activePciHostdevs, driver->inactivePciHostdevs) < 0) goto reattachdevs;
-
- 11 1月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
When sVirt is integrated with the LXC driver, it will be neccessary to invoke the security driver APIs using only a virDomainDefPtr since the lxc_container.c code has no virDomainObjPtr available. Aside from two functions which want obj->pid, every bit of the security driver code only touches obj->def. So we don't need to pass a virDomainObjPtr into the security drivers, a virDomainDefPtr is sufficient. Two functions also gain a 'pid_t pid' argument. * src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c, src/qemu/qemu_migration.c, src/qemu/qemu_process.c, src/security/security_apparmor.c, src/security/security_dac.c, src/security/security_driver.h, src/security/security_manager.c, src/security/security_manager.h, src/security/security_nop.c, src/security/security_selinux.c, src/security/security_stack.c: Change all security APIs to use a virDomainDefPtr instead of virDomainObjPtr
-
- 09 1月, 2012 1 次提交
-
-
由 Laine Stump 提交于
In the past, generic SCSI commands issued from a guest to a virtio disk were always passed through to the underlying disk by qemu, and the kernel would also pass them on. As a result of CVE-2011-4127 (see: http://seclists.org/oss-sec/2011/q4/536), qemu now honors its scsi=on|off device option for virtio-blk-pci (which enables/disables passthrough of generic SCSI commands), and the kernel will only allow the commands for physical devices (not for partitions or logical volumes). The default behavior of qemu is still to allow sending generic SCSI commands to physical disks that are presented to a guest as virtio-blk-pci devices, but libvirt prefers to disable those commands in the standard virtio block devices, enabling it only when specifically requested (hopefully indicating that the requester understands what they're asking for). For this purpose, a new libvirt disk device type (device='lun') has been created. device='lun' is identical to the default device='disk', except that: 1) It is only allowed if bus='virtio', type='block', and the qemu version is "new enough" to support it ("new enough" == qemu 0.11 or better), otherwise the domain will fail to start and a CONFIG_UNSUPPORTED error will be logged). 2) The option "scsi=on" will be added to the -device arg to allow SG_IO commands (if device !='lun', "scsi=off" will be added to the -device arg so that SG_IO commands are specifically forbidden). Guests which continue to use disk device='disk' (the default) will no longer be able to use SG_IO commands on the disk; those that have their disk device changed to device='lun' will still be able to use SG_IO commands. *docs/formatdomain.html.in - document the new device attribute value. *docs/schemas/domaincommon.rng - allow it in the RNG *tests/* - update the args of several existing tests to add scsi=off, and add one new test that will test scsi=on. *src/conf/domain_conf.c - update domain XML parser and formatter *src/qemu/qemu_(command|driver|hotplug).c - treat VIR_DOMAIN_DISK_DEVICE_LUN *almost* identically to VIR_DOMAIN_DISK_DEVICE_DISK, except as indicated above. Note that no support for this new device value was added to any hypervisor drivers other than qemu, because it's unclear what it might mean (if anything) to those drivers.
-
- 08 1月, 2012 1 次提交
-
-
由 Laine Stump 提交于
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=638633 Although scripts are not used by interfaces of type other than "ethernet" in qemu, due to the fact that the parser stores the script name in a union that is only valid when type is ethernet or bridge, there is no way for anyone except the parser itself to catch the problem of specifying an interface script for an inappropriate interface type (by the time the parsed data gets back to the code that called the parser, all evidence that a script was specified is forgotten). Since the parser itself should be agnostic to which type of interface allows scripts (an example of why: a script specified for an interface of type bridge is valid for xen domains, but not for qemu domains), the solution here is to move the script out of the union(s) in the DomainNetDef, always populate it when specified (regardless of interface type), and let the driver decide whether or not it is appropriate. Currently the qemu, xen, libxml, and uml drivers recognize the script parameter and do something with it (the uml driver only to report that it isn't supported). Those drivers have been updated to log a CONFIG_UNSUPPORTED error when a script is specified for an interface type that's inappropriate for that particular hypervisor. (NB: There was earlier discussion of solving this problem by adding a VALIDATE flag to all libvirt APIs that accept XML, which would cause the XML to be validated against the RNG files. One statement during that discussion was that the RNG shouldn't contain hypervisor-specific things, though, and a proper solution to this problem would require that (again, because a script for an interface of type "bridge" is accepted by xen, but not by qemu).
-
- 25 12月, 2011 1 次提交
-
-
由 Michal Privoznik 提交于
In order to avoid situation where a USB device is in use by two domains, we must keep a list of already attached devices like we do for PCI.
-
- 16 12月, 2011 1 次提交
-
-
由 Michal Privoznik 提交于
Currently, on device detach, we parse given XML, find the device in domain object, free it and try to restore security labels. However, in some cases (e.g. usb hostdev) parsed XML contains less information than freed device. In usb case it is bus & device IDs. These are needed during label restoring as a symlink into /dev/bus is generated from them. Therefore don't drop device configuration until security labels are restored.
-
- 15 12月, 2011 1 次提交
-
-
由 Osier Yang 提交于
This patch fixes two problems: 1) The device will be reattached to host even if it's not managed, as there is a "pciDeviceSetManaged". 2) The device won't be reattached to host with original driver properly. As it doesn't honor the device original properties which are maintained by driver->activePciHostdevs.
-
- 10 12月, 2011 1 次提交
-
-
由 Michael Ellerman 提交于
On the PPC64 pseries machine type we need to use the spapr-vscsi device rather than an lsi. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-
- 19 11月, 2011 3 次提交
-
-
由 Daniel P. Berrange 提交于
Rename virNetDevMacVLanCreate to virNetDevMacVLanCreateWithVPortProfile and virNetDevMacVLanDelete to virNetDevMacVLanDeleteWithVPortProfile To make way for renaming the other macvlan creation APIs in interface.c * util/virnetdevmacvlan.c, util/virnetdevmacvlan.h, qemu/qemu_command.c, qemu/qemu_hotplug.c, qemu/qemu_process.c: Rename APIs
-
由 Daniel P. Berrange 提交于
Rename the macvtap.c file to virnetdevmacvlan.c to reflect its functionality. Move the port profile association code out into virnetdevvportprofile.c. Make the APIs available unconditionally to callers * src/util/macvtap.h: rename to src/util/virnetdevmacvlan.h, * src/util/macvtap.c: rename to src/util/virnetdevmacvlan.c * src/util/virnetdevvportprofile.c, src/util/virnetdevvportprofile.h: Pull in vport association code * src/Makefile.am, src/conf/domain_conf.h, src/qemu/qemu_conf.c, src/qemu/qemu_conf.h, src/qemu/qemu_driver.c: Update include paths & remove conditional compilation
-
由 Daniel P. Berrange 提交于
In preparation for code re-organization, rename the Macvtap management APIs to have the following patterns virNetDevMacVLanXXXXX - macvlan/macvtap interface management virNetDevVPortProfileXXXX - virtual port profile management * src/util/macvtap.c, src/util/macvtap.h: Rename APIs * src/conf/domain_conf.c, src/network/bridge_driver.c, src/qemu/qemu_command.c, src/qemu/qemu_command.h, src/qemu/qemu_driver.c, src/qemu/qemu_hotplug.c, src/qemu/qemu_migration.c, src/qemu/qemu_process.c, src/qemu/qemu_process.h: Update for renamed APIs
-