libvirt/src/libvirt_private.syms

1214 lines
26 KiB
Plaintext
Raw Normal View History

#
# General private symbols. Add symbols here, and see Makefile.am for
# more details.
#
# Keep this file sorted by header name, then by symbols with each header.
#
# authhelper.h
virRequestPassword;
virRequestUsername;
# bitmap.h
virBitmapAlloc;
virBitmapClearBit;
virBitmapFree;
virBitmapGetBit;
virBitmapSetBit;
virBitmapString;
# buf.h
virBufferAdd;
virBufferAddChar;
virBufferAsprintf;
virBufferContentAndReset;
virBufferError;
virBufferEscapeSexpr;
virBufferEscapeString;
virBufferFreeAndReset;
virBufferStrcat;
virBufferURIEncodeString;
virBufferUse;
virBufferVasprintf;
# caps.h
virCapabilitiesAddGuest;
virCapabilitiesAddGuestDomain;
virCapabilitiesAddGuestFeature;
virCapabilitiesAddHostFeature;
virCapabilitiesAddHostMigrateTransport;
virCapabilitiesAddHostNUMACell;
virCapabilitiesAllocMachines;
virCapabilitiesDefaultGuestArch;
virCapabilitiesDefaultGuestEmulator;
virCapabilitiesDefaultGuestMachine;
virCapabilitiesFormatXML;
virCapabilitiesFree;
virCapabilitiesFreeMachines;
virCapabilitiesFreeNUMAInfo;
virCapabilitiesGenerateMac;
virCapabilitiesIsEmulatorRequired;
virCapabilitiesNew;
virCapabilitiesSetEmulatorRequired;
virCapabilitiesSetHostCPU;
virCapabilitiesSetMacPrefix;
# cgroup.h
virCgroupAddTask;
virCgroupAllowDeviceMajor;
virCgroupAllowDevicePath;
virCgroupControllerTypeFromString;
virCgroupControllerTypeToString;
virCgroupDenyAllDevices;
virCgroupDenyDevicePath;
virCgroupForDomain;
virCgroupForDriver;
virCgroupForVcpu;
virCgroupFree;
virCgroupGetBlkioWeight;
virCgroupGetCpuShares;
virCgroupGetCpuCfsPeriod;
virCgroupGetCpuCfsQuota;
virCgroupGetCpuacctUsage;
virCgroupGetFreezerState;
virCgroupGetMemoryHardLimit;
virCgroupGetMemorySoftLimit;
virCgroupGetMemoryUsage;
virCgroupGetMemSwapHardLimit;
virCgroupKill;
virCgroupKillPainfully;
virCgroupKillRecursive;
virCgroupMounted;
virCgroupPathOfController;
virCgroupRemove;
virCgroupSetBlkioWeight;
virCgroupSetCpuShares;
virCgroupSetCpuCfsPeriod;
virCgroupSetCpuCfsQuota;
virCgroupSetFreezerState;
virCgroupSetMemory;
virCgroupSetMemoryHardLimit;
virCgroupSetMemorySoftLimit;
virCgroupSetMemSwapHardLimit;
# command.h
virCommandAbort;
virCommandAddArg;
virCommandAddArgBuffer;
virCommandAddArgFormat;
virCommandAddArgList;
virCommandAddArgPair;
virCommandAddArgSet;
virCommandAddEnvBuffer;
virCommandAddEnvFormat;
virCommandAddEnvPair;
virCommandAddEnvPass;
virCommandAddEnvPassCommon;
virCommandAddEnvString;
virCommandClearCaps;
virCommandDaemonize;
virCommandExec;
virCommandFree;
virCommandHandshakeNotify;
virCommandHandshakeWait;
virCommandNew;
virCommandNewArgList;
virCommandNewArgs;
virCommandNonblockingFDs;
virCommandPreserveFD;
virCommandRequireHandshake;
virCommandRun;
virCommandRunAsync;
virCommandSetErrorBuffer;
virCommandSetErrorFD;
virCommandSetInputBuffer;
virCommandSetInputFD;
virCommandSetOutputBuffer;
virCommandSetOutputFD;
virCommandSetPidFile;
virCommandSetPreExecHook;
virCommandSetWorkingDirectory;
virCommandToString;
virCommandTransferFD;
virCommandTranslateStatus;
virCommandWait;
virCommandWriteArgLog;
virFork;
virPidAbort;
virPidWait;
virRun;
# conf.h
virConfFree;
virConfFreeValue;
virConfGetValue;
virConfNew;
virConfReadFile;
virConfReadMem;
virConfSetValue;
virConfWriteFile;
virConfWriteMem;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
# cpu.h
cpuBaseline;
cpuBaselineXML;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
cpuCompare;
cpuCompareXML;
cpuDataFree;
cpuDecode;
cpuEncode;
cpuGuestData;
cpuHasFeature;
cpuMapOverride;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
cpuNodeData;
cpuUpdate;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
# cpu_conf.h
virCPUDefAddFeature;
virCPUDefCopy;
virCPUDefFormat;
virCPUDefFormatBuf;
virCPUDefFree;
virCPUDefParseXML;
# datatypes.h
virGetDomain;
virGetDomainSnapshot;
virGetInterface;
virGetNWFilter;
virGetNetwork;
virGetNodeDevice;
virGetSecret;
virGetStoragePool;
virGetStorageVol;
virGetStream;
virUnrefConnect;
virUnrefDomain;
virUnrefNWFilter;
virUnrefSecret;
virUnrefStorageVol;
virUnrefStream;
# dnsmasq.h
dnsmasqAddDhcpHost;
dnsmasqAddHost;
dnsmasqContextFree;
dnsmasqContextNew;
dnsmasqDelete;
dnsmasqReload;
dnsmasqSave;
# domain_audit.h
virDomainAuditCgroup;
virDomainAuditCgroupMajor;
virDomainAuditCgroupPath;
virDomainAuditDisk;
virDomainAuditFS;
virDomainAuditHostdev;
virDomainAuditMemory;
virDomainAuditNet;
virDomainAuditNetDevice;
virDomainAuditRedirdev;
virDomainAuditSecurityLabel;
virDomainAuditStart;
virDomainAuditStop;
virDomainAuditVcpu;
# domain_conf.h
virDiskNameToBusDeviceIndex;
virDiskNameToIndex;
virDomainActualNetDefFree;
virDomainAssignDef;
virDomainBlockedReasonTypeFromString;
virDomainBlockedReasonTypeToString;
virDomainChrConsoleTargetTypeFromString;
virDomainChrConsoleTargetTypeToString;
virDomainChrDefForeach;
virDomainChrDefFree;
virDomainChrDefNew;
domain_conf: split source data out from ChrDef This opens up the possibility of reusing the smaller ChrSourceDef for both qemu monitor and a passthrough smartcard device. * src/conf/domain_conf.h (_virDomainChrDef): Factor host details... (_virDomainChrSourceDef): ...into new struct. (virDomainChrSourceDefFree): New prototype. * src/conf/domain_conf.c (virDomainChrDefFree) (virDomainChrDefParseXML, virDomainChrDefFormat): Split... (virDomainChrSourceDefClear, virDomainChrSourceDefFree) (virDomainChrSourceDefParseXML, virDomainChrSourceDefFormat): ...into new functions. (virDomainChrDefParseTargetXML): Update clients to reflect type split. * src/vmx/vmx.c (virVMXParseSerial, virVMXParseParallel) (virVMXFormatSerial, virVMXFormatParallel): Likewise. * src/xen/xen_driver.c (xenUnifiedDomainOpenConsole): Likewise. * src/xen/xend_internal.c (xenDaemonParseSxprChar) (xenDaemonFormatSxprChr): Likewise. * src/vbox/vbox_tmpl.c (vboxDomainDumpXML, vboxAttachSerial) (vboxAttachParallel): Likewise. * src/security/security_dac.c (virSecurityDACSetChardevLabel) (virSecurityDACSetChardevCallback) (virSecurityDACRestoreChardevLabel) (virSecurityDACRestoreChardevCallback): Likewise. * src/security/security_selinux.c (SELinuxSetSecurityChardevLabel) (SELinuxSetSecurityChardevCallback) (SELinuxRestoreSecurityChardevLabel) (SELinuxSetSecurityChardevCallback): Likewise. * src/security/virt-aa-helper.c (get_files): Likewise. * src/lxc/lxc_driver.c (lxcVmStart, lxcDomainOpenConsole): Likewise. * src/uml/uml_conf.c (umlBuildCommandLineChr): Likewise. * src/uml/uml_driver.c (umlIdentifyOneChrPTY, umlIdentifyChrPTY) (umlDomainOpenConsole): Likewise. * src/qemu/qemu_command.c (qemuBuildChrChardevStr) (qemuBuildChrArgStr, qemuBuildCommandLine) (qemuParseCommandLineChr): Likewise. * src/qemu/qemu_domain.c (qemuDomainObjPrivateXMLFormat) (qemuDomainObjPrivateXMLParse): Likewise. * src/qemu/qemu_cgroup.c (qemuSetupChardevCgroup): Likewise. * src/qemu/qemu_hotplug.c (qemuDomainAttachNetDevice): Likewise. * src/qemu/qemu_driver.c (qemudFindCharDevicePTYsMonitor) (qemudFindCharDevicePTYs, qemuPrepareChardevDevice) (qemuPrepareMonitorChr, qemudShutdownVMDaemon) (qemuDomainOpenConsole): Likewise. * src/qemu/qemu_command.h (qemuBuildChrChardevStr) (qemuBuildChrArgStr): Delete, now that they are static. * src/libvirt_private.syms (domain_conf.h): New exports. * cfg.mk (useless_free_options): Update list. * tests/qemuxml2argvtest.c (testCompareXMLToArgvFiles): Update tests.
2011-01-07 22:45:01 +00:00
virDomainChrSourceDefFree;
virDomainChrSpicevmcTypeFromString;
virDomainChrSpicevmcTypeToString;
virDomainChrTcpProtocolTypeFromString;
virDomainChrTcpProtocolTypeToString;
virDomainChrTypeFromString;
virDomainChrTypeToString;
virDomainClockOffsetTypeFromString;
virDomainClockOffsetTypeToString;
virDomainConfigFile;
virDomainControllerDefFree;
virDomainControllerInsert;
virDomainControllerInsertPreAlloced;
virDomainControllerModelUSBTypeFromString;
virDomainControllerModelUSBTypeToString;
virDomainControllerModelSCSITypeFromString;
virDomainControllerModelSCSITypeToString;
virDomainControllerTypeToString;
virDomainCpuSetFormat;
virDomainCpuSetParse;
virDomainDefAddImplicitControllers;
virDomainDefCheckABIStability;
virDomainDefClearDeviceAliases;
virDomainDefClearPCIAddresses;
virDomainDefFormat;
virDomainDefFree;
virDomainDefParseFile;
virDomainDefParseNode;
virDomainDefParseString;
virDomainDeleteConfig;
virDomainDeviceAddressIsValid;
virDomainDeviceAddressTypeToString;
virDomainDeviceDefFree;
virDomainDeviceDefParse;
virDomainDeviceInfoIterate;
virDomainDevicePCIAddressIsValid;
virDomainDeviceTypeToString;
virDomainDiskBusTypeToString;
virDomainDiskCacheTypeFromString;
virDomainDiskCacheTypeToString;
virDomainDiskDefAssignAddress;
virDomainDiskDefForeachPath;
virDomainDiskDefFree;
virDomainDiskDeviceTypeToString;
virDomainDiskErrorPolicyTypeFromString;
virDomainDiskErrorPolicyTypeToString;
virDomainDiskIndexByName;
virDomainDiskInsert;
virDomainDiskInsertPreAlloced;
virDomainDiskIoTypeFromString;
virDomainDiskIoTypeToString;
snapshot: also support disks by path I got confused when 'virsh domblkinfo dom disk' required the path to a disk (which can be ambiguous, since a single file can back multiple disks), rather than the unambiguous target device name that I was using in disk snapshots. So, in true developer fashion, I went for the best of both worlds - all interfaces that operate on a disk (aka block) now accept either the target name or the unambiguous path to the backing file used by the disk. * src/conf/domain_conf.h (virDomainDiskIndexByName): Add parameter. (virDomainDiskPathByName): New prototype. * src/libvirt_private.syms (domain_conf.h): Export it. * src/conf/domain_conf.c (virDomainDiskIndexByName): Also allow searching by path, and decide whether ambiguity is okay. (virDomainDiskPathByName): New function. (virDomainDiskRemoveByName, virDomainSnapshotAlignDisks): Update callers. * src/qemu/qemu_driver.c (qemudDomainBlockPeek) (qemuDomainAttachDeviceConfig, qemuDomainUpdateDeviceConfig) (qemuDomainGetBlockInfo, qemuDiskPathToAlias): Likewise. * src/qemu/qemu_process.c (qemuProcessFindDomainDiskByPath): Likewise. * src/libxl/libxl_driver.c (libxlDomainAttachDeviceDiskLive) (libxlDomainDetachDeviceDiskLive, libxlDomainAttachDeviceConfig) (libxlDomainUpdateDeviceConfig): Likewise. * src/uml/uml_driver.c (umlDomainBlockPeek): Likewise. * src/xen/xend_internal.c (xenDaemonDomainBlockPeek): Likewise. * docs/formatsnapshot.html.in: Update documentation. * tools/virsh.pod (domblkstat, domblkinfo): Likewise. * docs/schemas/domaincommon.rng (diskTarget): Tighten pattern on disk targets. * docs/schemas/domainsnapshot.rng (disksnapshot): Update to match. * tests/domainsnapshotxml2xmlin/disk_snapshot.xml: Update test.
2011-08-20 02:38:36 +00:00
virDomainDiskPathByName;
virDomainDiskRemove;
virDomainDiskRemoveByName;
virDomainDiskSnapshotTypeFromString;
virDomainDiskSnapshotTypeToString;
virDomainDiskTypeFromString;
virDomainDiskTypeToString;
virDomainFSDefFree;
virDomainFSTypeFromString;
virDomainFSTypeToString;
virDomainFindByID;
virDomainFindByName;
virDomainFindByUUID;
virDomainGetRootFilesystem;
virDomainGraphicsAuthConnectedTypeFromString;
virDomainGraphicsAuthConnectedTypeToString;
virDomainGraphicsDefFree;
conf: add <listen> subelement to domain <graphics> element Once it's plugged in, the <listen> element will be an optional replacement for the "listen" attribute that graphics elements already have. If the <listen> element is type='address', it will have an attribute called 'address' which will contain an IP address or dns name that the guest's display server should listen on. If, however, type='network', the <listen> element should have an attribute called 'network' that will be set to the name of a network configuration to get the IP address from. * docs/schemas/domain.rng: updated to allow the <listen> element * docs/formatdomain.html.in: document the <listen> element and its attributes. * src/conf/domain_conf.[hc]: 1) The domain parser, formatter, and data structure are modified to support 0 or more <listen> subelements to each <graphics> element. The old style "legacy" listen attribute is also still accepted, and will be stored internally just as if it were a separate <listen> element. On output (i.e. format), the address attribute of the first <listen> element of type 'address' will be duplicated in the legacy "listen" attribute of the <graphic> element. 2) The "listenAddr" attribute has been removed from the unions in virDomainGRaphicsDef for graphics types vnc, rdp, and spice. This attribute is now in the <listen> subelement (aka virDomainGraphicsListenDef) 3) Helper functions were written to provide simple access (both Get and Set) to the listen elements and their attributes. * src/libvirt_private.syms: export the listen helper functions * src/qemu/qemu_command.c, src/qemu/qemu_hotplug.c, src/qemu/qemu_migration.c, src/vbox/vbox_tmpl.c, src/vmx/vmx.c, src/xenxs/xen_sxpr.c, src/xenxs/xen_xm.c Modify all these files to use the listen helper functions rather than directly referencing the (now missing) listenAddr attribute. There can be multiple <listen> elements to a single <graphics>, but the drivers all currently only support one, so all replacements of direct access with a helper function indicate index "0". * tests/* - only 3 of these are new files added explicitly to test the new <listen> element. All the others have been modified to reflect the fact that any legacy "listen" attributes passed in to the domain parse will be saved in a <listen> element (i.e. one of the virDomainGraphicsListenDefs), and during the domain format function, both the <listen> element as well as the legacy attributes will be output.
2011-07-07 04:20:28 +00:00
virDomainGraphicsListenGetAddress;
virDomainGraphicsListenGetNetwork;
virDomainGraphicsListenGetType;
virDomainGraphicsListenSetAddress;
virDomainGraphicsListenSetNetwork;
virDomainGraphicsListenSetType;
virDomainGraphicsSpiceChannelModeTypeFromString;
virDomainGraphicsSpiceChannelModeTypeToString;
virDomainGraphicsSpiceChannelNameTypeFromString;
virDomainGraphicsSpiceChannelNameTypeToString;
virDomainGraphicsSpiceClipboardCopypasteTypeFromString;
virDomainGraphicsSpiceClipboardCopypasteTypeToString;
virDomainGraphicsSpiceImageCompressionTypeFromString;
virDomainGraphicsSpiceImageCompressionTypeToString;
virDomainGraphicsSpiceJpegCompressionTypeFromString;
virDomainGraphicsSpiceJpegCompressionTypeToString;
virDomainGraphicsSpicePlaybackCompressionTypeFromString;
virDomainGraphicsSpicePlaybackCompressionTypeToString;
virDomainGraphicsSpiceStreamingModeTypeFromString;
virDomainGraphicsSpiceStreamingModeTypeToString;
virDomainGraphicsSpiceZlibCompressionTypeFromString;
virDomainGraphicsSpiceZlibCompressionTypeToString;
virDomainGraphicsTypeFromString;
virDomainGraphicsTypeToString;
2009-04-24 12:19:00 +00:00
virDomainHostdevDefFree;
virDomainHostdevModeTypeToString;
virDomainHostdevSubsysTypeToString;
virDomainHubTypeFromString;
virDomainHubTypeToString;
virDomainInputDefFree;
virDomainIoEventFdTypeFromString;
virDomainIoEventFdTypeToString;
virDomainLeaseIndex;
virDomainLeaseInsert;
virDomainLeaseInsertPreAlloc;
virDomainLeaseInsertPreAlloced;
virDomainLeaseRemove;
virDomainLeaseRemoveAt;
virDomainLifecycleCrashTypeFromString;
virDomainLifecycleCrashTypeToString;
virDomainLifecycleTypeFromString;
virDomainLifecycleTypeToString;
virDomainLoadAllConfigs;
virDomainMemballoonModelTypeFromString;
virDomainMemballoonModelTypeToString;
virDomainNetDefFree;
virDomainNetGetActualBandwidth;
virDomainNetGetActualBridgeName;
virDomainNetGetActualDirectDev;
virDomainNetGetActualDirectMode;
virDomainNetGetActualType;
virDomainNetGetActualDirectVirtPortProfile;
virDomainNetIndexByMac;
virDomainNetInsert;
virDomainNetRemoveByMac;
virDomainNetTypeToString;
virDomainNostateReasonTypeFromString;
virDomainNostateReasonTypeToString;
virDomainNumatuneMemModeTypeFromString;
virDomainNumatuneMemModeTypeToString;
virDomainObjAssignDef;
virDomainObjCopyPersistentDef;
virDomainObjGetPersistentDef;
virDomainObjGetState;
virDomainObjIsDuplicate;
virDomainObjListDeinit;
virDomainObjListGetActiveIDs;
virDomainObjListGetInactiveNames;
virDomainObjListInit;
virDomainObjListNumOfDomains;
virDomainObjLock;
virDomainObjRef;
virDomainObjSetDefTransient;
virDomainObjSetState;
virDomainObjTaint;
virDomainObjUnlock;
virDomainObjUnref;
virDomainPausedReasonTypeFromString;
virDomainPausedReasonTypeToString;
virDomainRedirdevBusTypeFromString;
virDomainRedirdevBusTypeToString;
virDomainRemoveInactive;
virDomainRunningReasonTypeFromString;
virDomainRunningReasonTypeToString;
virDomainSaveConfig;
virDomainSaveStatus;
virDomainSaveXML;
virDomainShutdownReasonTypeFromString;
virDomainShutdownReasonTypeToString;
virDomainShutoffReasonTypeFromString;
virDomainShutoffReasonTypeToString;
virDomainSmartcardDefForeach;
virDomainSmartcardDefFree;
virDomainSmartcardTypeFromString;
virDomainSmartcardTypeToString;
virDomainSnapshotAlignDisks;
virDomainSnapshotAssignDef;
virDomainSnapshotDefFormat;
virDomainSnapshotDefFree;
virDomainSnapshotDefParseString;
virDomainSnapshotFindByName;
virDomainSnapshotForEachChild;
snapshot: avoid crash when deleting qemu snapshots This one's nasty. Ever since we fixed virHashForEach to prevent nested hash iterations for safety reasons (commit fba550f6), virDomainSnapshotDelete with VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN has been broken for qemu: it deletes children, while leaving grandchildren intact but pointing to a no-longer-present parent. But even before then, the code would often appear to succeed to clean up grandchildren, but risked memory corruption if you have a large and deep hierarchy of snapshots. For acting on just children, a single virHashForEach is sufficient. But for acting on an entire subtree, it requires iteration; and since we declared recursion as invalid, we have to switch to a while loop. Doing this correctly requires quite a bit of overhaul, so I added a new helper function to isolate the algorithm from the actions, so that callers do not have to reinvent the iteration. Note that this _still_ does not handle CHILDREN correctly if one of the children is the current snapshot; that will be next. * src/conf/domain_conf.h (_virDomainSnapshotDef): Add mark. (virDomainSnapshotForEachDescendant): New prototype. * src/libvirt_private.syms (domain_conf.h): Export it. * src/conf/domain_conf.c (virDomainSnapshotMarkDescendant) (virDomainSnapshotActOnDescendant) (virDomainSnapshotForEachDescendant): New functions. * src/qemu/qemu_driver.c (qemuDomainSnapshotDiscardChildren): Replace... (qemuDomainSnapshotDiscardDescenent): ...with callback that doesn't nest hash traversal. (qemuDomainSnapshotDelete): Use new function.
2011-08-12 13:05:50 +00:00
virDomainSnapshotForEachDescendant;
virDomainSnapshotHasChildren;
virDomainSnapshotObjListGetNames;
virDomainSnapshotObjListNum;
virDomainSnapshotObjListRemove;
virDomainSnapshotStateTypeFromString;
virDomainSnapshotStateTypeToString;
virDomainSoundDefFree;
virDomainSoundModelTypeFromString;
virDomainSoundModelTypeToString;
virDomainStateReasonFromString;
virDomainStateReasonToString;
virDomainStateTypeFromString;
virDomainStateTypeToString;
virDomainTaintTypeFromString;
virDomainTaintTypeToString;
virDomainTimerModeTypeFromString;
virDomainTimerModeTypeToString;
virDomainTimerNameTypeFromString;
virDomainTimerNameTypeToString;
virDomainTimerTickpolicyTypeFromString;
virDomainTimerTickpolicyTypeToString;
virDomainTimerTrackTypeFromString;
virDomainTimerTrackTypeToString;
virDomainVcpuPinAdd;
virDomainVcpuPinDel;
virDomainVcpuPinFindByVcpu;
virDomainVcpuPinIsDuplicate;
virDomainVideoDefFree;
virDomainVideoDefaultRAM;
virDomainVideoDefaultType;
virDomainVideoTypeFromString;
virDomainVideoTypeToString;
qemu: support event_idx parameter for virtio disk and net devices In some versions of qemu, both virtio-blk-pci and virtio-net-pci devices can have an event_idx setting that determines some details of event processing. When it is enabled, it "reduces the number of interrupts and exits for the guest". qemu will automatically enable this feature when it is available, but there may be cases where this new feature could actually make performance worse (NB: no such case has been found so far). As a safety switch in case such a situation is encountered in the field, this patch adds a new attribute "event_idx" to the <driver> element of both disk and interface devices. event_idx can be set to "on" (to force event_idx on in case qemu has it disabled by default) or "off" (for force event_idx off). In the case that event_idx support isn't present in qemu, the attribute is ignored (this on the advice of the qemu developer). docs/formatdomain.html.in: document the new flag (marking it as "don't mess with this!" docs/schemas/domain.rng: add event_idx in appropriate places src/conf/domain_conf.[ch]: add event_idx to parser and formatter src/libvirt_private.syms: export virDomainVirtioEventIdx(From|To)String src/qemu/qemu_capabilities.[ch]: detect and report event_idx in disk/net src/qemu/qemu_command.c: add event_idx parameter to qemu commandline when appropriate. tests/qemuxml2argvdata/qemuxml2argv-event_idx.args, tests/qemuxml2argvdata/qemuxml2argv-event_idx.xml, tests/qemuxml2argvtest.c, tests/qemuxml2xmltest.c: test cases for event_idx.
2011-08-13 06:32:45 +00:00
virDomainVirtioEventIdxTypeFromString;
virDomainVirtioEventIdxTypeToString;
virDomainVirtTypeToString;
virDomainWatchdogActionTypeFromString;
virDomainWatchdogActionTypeToString;
virDomainWatchdogModelTypeFromString;
virDomainWatchdogModelTypeToString;
# domain_event.h
virDomainEventBlockJobNewFromObj;
virDomainEventBlockJobNewFromDom;
virDomainEventCallbackListAdd;
virDomainEventCallbackListAddID;
virDomainEventCallbackListCount;
virDomainEventCallbackListCountID;
virDomainEventCallbackListEventID;
virDomainEventCallbackListFree;
virDomainEventCallbackListMarkDelete;
virDomainEventCallbackListMarkDeleteID;
virDomainEventCallbackListPurgeMarked;
virDomainEventCallbackListRemove;
virDomainEventCallbackListRemoveConn;
virDomainEventCallbackListRemoveID;
virDomainEventControlErrorNewFromDom;
virDomainEventControlErrorNewFromObj;
virDomainEventDispatch;
virDomainEventDispatchDefaultFunc;
virDomainEventFree;
virDomainEventGraphicsNewFromDom;
virDomainEventGraphicsNewFromObj;
virDomainEventIOErrorNewFromDom;
virDomainEventIOErrorNewFromObj;
virDomainEventIOErrorReasonNewFromDom;
virDomainEventIOErrorReasonNewFromObj;
virDomainEventNew;
virDomainEventNewFromDef;
virDomainEventNewFromDom;
virDomainEventNewFromObj;
virDomainEventQueueDispatch;
virDomainEventQueueFree;
virDomainEventQueueNew;
virDomainEventQueuePop;
virDomainEventQueuePush;
virDomainEventRTCChangeNewFromDom;
virDomainEventRTCChangeNewFromObj;
virDomainEventRebootNew;
virDomainEventRebootNewFromDom;
virDomainEventRebootNewFromObj;
virDomainEventStateDeregister;
virDomainEventStateDeregisterAny;
virDomainEventStateFlush;
virDomainEventStateFree;
virDomainEventStateNew;
virDomainEventStateQueue;
virDomainEventWatchdogNewFromDom;
virDomainEventWatchdogNewFromObj;
# domain_lock.h
virDomainLockProcessStart;
virDomainLockProcessInquire;
virDomainLockProcessPause;
virDomainLockProcessResume;
virDomainLockDiskAttach;
virDomainLockDiskDetach;
virDomainLockLeaseAttach;
virDomainLockLeaseDetach;
# domain_nwfilter.h
virDomainConfNWFilterInstantiate;
virDomainConfNWFilterRegister;
virDomainConfNWFilterTeardown;
virDomainConfVMNWFilterTeardown;
# ebtables.h
ebtablesAddForwardAllowIn;
ebtablesAddForwardPolicyReject;
ebtablesContextFree;
ebtablesContextNew;
ebtablesRemoveForwardAllowIn;
# event_poll.h
virEventPollToNativeEvents;
virEventPollFromNativeEvents;
# fdstream.h
virFDStreamOpen;
virFDStreamConnectUNIX;
virFDStreamOpenFile;
virFDStreamCreateFile;
# hash.h
virHashAddEntry;
virHashCreate;
virHashForEach;
virHashFree;
virHashLookup;
virHashRemoveEntry;
virHashRemoveSet;
virHashSearch;
virHashSize;
virHashSteal;
virHashTableSize;
# hooks.h
virHookCall;
virHookInitialize;
virHookPresent;
# interface.h
ifaceCheck;
ifaceCtrl;
ifaceGetFlags;
ifaceGetIndex;
ifaceGetMacAddress;
ifaceGetIPAddress;
ifaceGetNthParent;
ifaceGetPhysicalFunction;
ifaceGetVirtualFunctionIndex;
ifaceGetVlanID;
ifaceIsUp;
ifaceIsVirtualFunction;
ifaceLinkDel;
ifaceMacvtapLinkAdd;
ifaceMacvtapLinkDump;
ifaceReplaceMacAddress;
ifaceRestoreMacAddress;
ifaceSetMacAddress;
# interface_conf.h
virInterfaceAssignDef;
virInterfaceDefFormat;
virInterfaceDefFree;
virInterfaceDefParseFile;
virInterfaceDefParseNode;
virInterfaceDefParseString;
virInterfaceFindByMACString;
virInterfaceFindByName;
virInterfaceObjListClone;
virInterfaceObjListFree;
virInterfaceObjLock;
virInterfaceObjUnlock;
virInterfaceRemove;
# iptables.h
iptablesAddForwardAllowCross;
iptablesAddForwardAllowIn;
iptablesAddForwardAllowOut;
iptablesAddForwardAllowRelatedIn;
iptablesAddForwardMasquerade;
iptablesAddForwardRejectIn;
iptablesAddForwardRejectOut;
iptablesAddOutputFixUdpChecksum;
iptablesAddTcpInput;
iptablesAddUdpInput;
iptablesContextFree;
iptablesContextNew;
iptablesRemoveForwardAllowCross;
iptablesRemoveForwardAllowIn;
iptablesRemoveForwardAllowOut;
iptablesRemoveForwardAllowRelatedIn;
iptablesRemoveForwardMasquerade;
iptablesRemoveForwardRejectIn;
iptablesRemoveForwardRejectOut;
iptablesRemoveOutputFixUdpChecksum;
iptablesRemoveTcpInput;
iptablesRemoveUdpInput;
# json.h
virJSONValueArrayAppend;
virJSONValueArrayGet;
virJSONValueArraySize;
virJSONValueFree;
virJSONValueFromString;
virJSONValueGetBoolean;
virJSONValueGetNumberDouble;
virJSONValueGetNumberInt;
virJSONValueGetNumberLong;
virJSONValueGetNumberUint;
virJSONValueGetNumberUlong;
virJSONValueGetString;
virJSONValueIsNull;
virJSONValueNewArray;
virJSONValueNewBoolean;
virJSONValueNewNull;
virJSONValueNewNumberDouble;
virJSONValueNewNumberInt;
virJSONValueNewNumberLong;
virJSONValueNewNumberUint;
virJSONValueNewNumberUlong;
virJSONValueNewObject;
virJSONValueNewString;
virJSONValueNewStringLen;
virJSONValueObjectAppend;
virJSONValueObjectAppendBoolean;
virJSONValueObjectAppendNull;
virJSONValueObjectAppendNumberDouble;
virJSONValueObjectAppendNumberInt;
virJSONValueObjectAppendNumberLong;
virJSONValueObjectAppendNumberUint;
virJSONValueObjectAppendNumberUlong;
virJSONValueObjectAppendString;
virJSONValueObjectGet;
virJSONValueObjectGetBoolean;
virJSONValueObjectGetNumberDouble;
virJSONValueObjectGetNumberInt;
virJSONValueObjectGetNumberLong;
virJSONValueObjectGetNumberUint;
virJSONValueObjectGetNumberUlong;
virJSONValueObjectGetString;
virJSONValueObjectHasKey;
virJSONValueObjectIsNull;
virJSONValueToString;
# libvirt_internal.h
virDomainMigrateFinish2;
virDomainMigrateFinish;
virDomainMigratePerform;
virDomainMigratePrepare2;
virDomainMigratePrepare;
virDomainMigratePrepareTunnel;
Introduce yet another migration version in API. Migration just seems to go from bad to worse. We already had to introduce a second migration protocol when adding the QEMU driver, since the one from Xen was insufficiently flexible to cope with passing the data the QEMU driver required. It turns out that this protocol still has some flaws that we need to address. The current sequence is * Src: DumpXML - Generate XML to pass to dst * Dst: Prepare - Get ready to accept incoming VM - Generate optional cookie to pass to src * Src: Perform - Start migration and wait for send completion - Kill off VM if successful, resume if failed * Dst: Finish - Wait for recv completion and check status - Kill off VM if unsuccessful The problems with this are: - Since the first step is a generic 'DumpXML' call, we can't add in other migration specific data. eg, we can't include any VM lease data from lock manager plugins - Since the first step is a generic 'DumpXML' call, we can't emit any 'migration begin' event on the source, or have any hook that runs right at the start of the process - Since there is no final step on the source, if the Finish method fails to receive all migration data & has to kill the VM, then there's no way to resume the original VM on the source This patch attempts to introduce a version 3 that uses the improved 5 step sequence * Src: Begin - Generate XML to pass to dst - Generate optional cookie to pass to dst * Dst: Prepare - Get ready to accept incoming VM - Generate optional cookie to pass to src * Src: Perform - Start migration and wait for send completion - Generate optional cookie to pass to dst * Dst: Finish - Wait for recv completion and check status - Kill off VM if failed, resume if success - Generate optional cookie to pass to src * Src: Confirm - Kill off VM if success, resume if failed The API is designed to allow both input and output cookies in all methods where applicable. This lets us pass around arbitrary extra driver specific data between src & dst during migration. Combined with the extra 'Begin' method this lets us pass lease information from source to dst at the start of migration Moving the killing of the source VM out of Perform and into Confirm, means we can now recover if the dst host can't successfully Finish receiving migration data.
2010-11-02 12:43:44 +00:00
virDomainMigrateBegin3;
virDomainMigratePrepare3;
virDomainMigratePrepareTunnel3;
virDomainMigratePerform3;
virDomainMigrateFinish3;
virDomainMigrateConfirm3;
virDrvSupportsFeature;
virRegisterDeviceMonitor;
virRegisterDriver;
virRegisterInterfaceDriver;
virRegisterNWFilterDriver;
virRegisterNetworkDriver;
virRegisterSecretDriver;
virRegisterStorageDriver;
# locking.h
virLockManagerAcquire;
virLockManagerAddResource;
virLockManagerFree;
virLockManagerInquire;
virLockManagerNew;
virLockManagerPluginNew;
virLockManagerPluginRef;
virLockManagerPluginUnref;
virLockManagerPluginUsesState;
virLockManagerPluginGetName;
virLockManagerRelease;
# logging.h
virLogDefineFilter;
virLogDefineOutput;
virLogEmergencyDumpAll;
virLogGetDefaultPriority;
virLogGetFilters;
virLogGetNbFilters;
virLogGetNbOutputs;
virLogGetOutputs;
virLogLock;
virLogMessage;
virLogParseDefaultPriority;
virLogParseFilters;
virLogParseOutputs;
virLogReset;
virLogSetBufferSize;
virLogSetDefaultPriority;
virLogSetFromEnv;
virLogShutdown;
virLogStartup;
virLogUnlock;
# macvtap.h
virVMOperationTypeFromString;
virVMOperationTypeToString;
# memory.h
virAlloc;
virAllocN;
virAllocVar;
virExpandN;
virFree;
virReallocN;
virResizeN;
virShrinkN;
#netlink.h
nlComm;
# network.h
virBandwidthCopy;
2011-07-22 14:07:26 +00:00
virBandwidthDefFormat;
virBandwidthDefFree;
virBandwidthDefParseNode;
virBandwidthDisable;
virBandwidthEnable;
virBandwidthEqual;
virSocketAddrBroadcast;
virSocketAddrBroadcastByPrefix;
virSocketAddrIsNetmask;
virSocketAddrMask;
virSocketAddrMaskByPrefix;
virSocketAddrPrefixToNetmask;
virSocketCheckNetmask;
virSocketFormatAddr;
virSocketFormatAddrFull;
virSocketGetPort;
virSocketGetRange;
virSocketParseAddr;
virSocketParseIpv4Addr;
virSocketParseIpv6Addr;
virSocketSetPort;
virVirtualPortProfileEqual;
virVirtualPortProfileFormat;
virVirtualPortProfileParseXML;
# network_conf.h
virNetworkAssignDef;
virNetworkConfigFile;
virNetworkDefFormat;
virNetworkDefFree;
virNetworkDefGetIpByIndex;
virNetworkDefParseFile;
virNetworkDefParseNode;
virNetworkDefParseString;
virNetworkDeleteConfig;
virNetworkFindByName;
virNetworkFindByUUID;
virNetworkIpDefNetmask;
virNetworkIpDefPrefix;
virNetworkLoadAllConfigs;
virNetworkObjIsDuplicate;
virNetworkObjListFree;
virNetworkObjLock;
virNetworkObjUnlock;
virNetworkRemoveInactive;
virNetworkSaveConfig;
Give each virtual network bridge its own fixed MAC address This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463 The problem was that, since a bridge always acquires the MAC address of the connected interface with the numerically lowest MAC, as guests are started and stopped, it was possible for the MAC address to change over time, and this change in the network was being detected by Windows 7 (it sees the MAC of the default route change), so on each reboot it would bring up a dialog box asking about this "new network". The solution is to create a dummy tap interface with a MAC guaranteed to be lower than any guest interface's MAC, and attach that tap to the bridge as soon as it's created. Since all guest MAC addresses start with 0xFE, we can just generate a MAC with the standard "0x52, 0x54, 0" prefix, and it's guaranteed to always win (physical interfaces are never connected to these bridges, so we don't need to worry about competing numerically with them). Note that the dummy tap is never set to IFF_UP state - that's not necessary in order for the bridge to take its MAC, and not setting it to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed in the output of the ifconfig command. I chose to not auto-generate the MAC address in the network XML parser, as there are likely to be consumers of that API that don't need or want to have a MAC address associated with the bridge. Instead, in bridge_driver.c when the network is being defined, if there is no MAC, one is generated. To account for virtual network configs that already exist when upgrading from an older version of libvirt, I've added a %post script to the specfile that searches for all network definitions in both the config directory (/etc/libvirt/qemu/networks) and the state directory (/var/lib/libvirt/network) that are missing a mac address, generates a random address, and adds it to the config (and a matching address to the state file, if there is one). docs/formatnetwork.html.in: document <mac address.../> docs/schemas/network.rng: add nac address to schema libvirt.spec.in: %post script to update existing networks src/conf/network_conf.[ch]: parse and format <mac address.../> src/libvirt_private.syms: export a couple private symbols we need src/network/bridge_driver.c: auto-generate mac address when needed, create dummy interface if mac address is present. tests/networkxml2xmlin/isolated-network.xml tests/networkxml2xmlin/routed-network.xml tests/networkxml2xmlout/isolated-network.xml tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
2011-02-09 08:28:12 +00:00
virNetworkSetBridgeMacAddr;
virNetworkSetBridgeName;
conf: support abstracted interface info in network XML The network XML is updated in the following ways: 1) The <forward> element can now contain a list of forward interfaces: <forward .... > <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> </forward> The first of these takes the place of the dev attribute that is normally in <forward> - when defining a network you can specify either one, and on output both will be present. If you specify both on input, they must match. 2) In addition to forward modes of 'nat' and 'route', these new modes are supported: private, passthrough, vepa - when this network is referenced by a domain's interface, it will have the same effect as if the interface had been defined as type='direct', e.g.: <interface type='direct'> <source mode='${mode}' dev='${dev}> ... </interface> where ${mode} is one of the three new modes, and ${dev} is an interface selected from the list given in <forward>. bridge - if a <forward> dev (or multiple devs) is defined, and forward mode is 'bridge' this is just like the modes 'private', 'passthrough', and 'vepa' above. If there is no forward dev specified but a bridge name is given (e.g. "<bridge name='br0'/>"), then guest interfaces using this network will use libvirt's "host bridge" mode, equivalent to this: <interface type='bridge'> <source bridge='${bridge-name}'/> ... </interface> 3) A network can have multiple <portgroup> elements, which may be selected by the guest interface definition (by adding "portgroup='${name}'" in the <source> element along with the network name). Currently a portgroup can only contain a virtportprofile, but the intent is that other configuration items may be put there int the future (e.g. bandwidth config). When building a guest's interface, if the <interface> XML itself has no virtportprofile, and if the requested network has a portgroup with a name matching the name given in the <interface> (or if one of the network's portgroups is marked with the "default='yes'" attribute), the virtportprofile from that portgroup will be used by the interface. 4) A network can have a virtportprofile defined at the top level, which will be used by a guest interface when connecting in one of the 'direct' modes if the guest interface XML itself hasn't specified any virtportprofile, and if there are also no matching portgroups on the network.
2011-07-20 03:01:09 +00:00
virPortGroupFindByName;
# node_device_conf.h
virNodeDevCapTypeToString;
virNodeDevCapsDefFree;
virNodeDeviceAssignDef;
virNodeDeviceDefFormat;
virNodeDeviceDefFree;
virNodeDeviceDefParseFile;
virNodeDeviceDefParseNode;
virNodeDeviceDefParseString;
virNodeDeviceFindByName;
virNodeDeviceFindBySysfsPath;
virNodeDeviceGetParentHost;
virNodeDeviceGetWWNs;
virNodeDeviceHasCap;
virNodeDeviceObjListFree;
virNodeDeviceObjLock;
virNodeDeviceObjRemove;
virNodeDeviceObjUnlock;
# nodeinfo.h
nodeCapsInitNUMA;
nodeGetCPUStats;
nodeGetCellsFreeMemory;
nodeGetFreeMemory;
nodeGetInfo;
nodeGetMemoryStats;
# nwfilter_conf.h
virNWFilterCallbackDriversLock;
virNWFilterCallbackDriversUnlock;
virNWFilterChainSuffixTypeToString;
virNWFilterConfLayerInit;
virNWFilterConfLayerShutdown;
virNWFilterDefFormat;
virNWFilterDefFree;
virNWFilterDefParseString;
virNWFilterJumpTargetTypeToString;
virNWFilterLoadAllConfigs;
virNWFilterLockFilterUpdates;
virNWFilterObjAssignDef;
virNWFilterObjDeleteDef;
virNWFilterObjFindByName;
virNWFilterObjFindByUUID;
virNWFilterObjListFree;
virNWFilterObjLock;
virNWFilterObjRemove;
virNWFilterObjSaveDef;
virNWFilterObjUnlock;
virNWFilterPrintStateMatchFlags;
virNWFilterPrintTCPFlags;
virNWFilterRegisterCallbackDriver;
virNWFilterRuleActionTypeToString;
virNWFilterRuleProtocolTypeToString;
virNWFilterTestUnassignDef;
nwfilter: Support for learning a VM's IP address This patch implements support for learning a VM's IP address. It uses the pcap library to listen on the VM's backend network interface (tap) or the physical ethernet device (macvtap) and tries to capture packets with source or destination MAC address of the VM and learn from DHCP Offers, ARP traffic, or first-sent IPv4 packet what the IP address of the VM's interface is. This then allows to instantiate the network traffic filtering rules without the user having to provide the IP parameter somewhere in the filter description or in the interface description as a parameter. This only supports to detect the parameter IP, which is for the assumed single IPv4 address of a VM. There is not support for interfaces that may have multiple IP addresses (IP aliasing) or IPv6 that may then require more than one valid IP address to be detected. A VM can have multiple independent interfaces that each uses a different IP address and in that case it will be attempted to detect each one of the address independently. So, when for example an interface description in the domain XML has looked like this up to now: <interface type='bridge'> <source bridge='mybridge'/> <model type='virtio'/> <filterref filter='clean-traffic'> <parameter name='IP' value='10.2.3.4'/> </filterref> </interface> you may omit the IP parameter: <interface type='bridge'> <source bridge='mybridge'/> <model type='virtio'/> <filterref filter='clean-traffic'/> </interface> Internally I am walking the 'tree' of a VM's referenced network filters and determine with the given variables which variables are missing. Now, the above IP parameter may be missing and this causes a libvirt-internal thread to be started that uses the pcap library's API to listen to the backend interface (in case of macvtap to the physical interface) in an attempt to determine the missing IP parameter. If the backend interface disappears the thread terminates assuming the VM was brought down. In case of a macvtap device a timeout is being used to wait for packets from the given VM (filtering by VM's interface MAC address). If the VM's macvtap device disappeared the thread also terminates. In all other cases it tries to determine the IP address of the VM and will then apply the rules late on the given interface, which would have happened immediately if the IP parameter had been explicitly given. In case an error happens while the firewall rules are applied, the VM's backend interface is 'down'ed preventing it to communicate. Reasons for failure for applying the network firewall rules may that an ebtables/iptables command failes or OOM errors. Essentially the same failure reasons may occur as when the firewall rules are applied immediately on VM start, except that due to the late application of the filtering rules the VM now is already running and cannot be hindered anymore from starting. Bringing down the whole VM would probably be considered too drastic. While a VM's IP address is attempted to be determined only limited updates to network filters are allowed. In particular it is prevented that filters are modified in such a way that they would introduce new variables. A caveat: The algorithm does not know which one is the appropriate IP address of a VM. If the VM spoofs an IP address in its first ARP traffic or IPv4 packets its filtering rules will be instantiated for this IP address, thus 'locking' it to the found IP address. So, it's still 'safer' to explicitly provide the IP address of a VM's interface in the filter description if it is known beforehand. * configure.ac: detect libpcap * libvirt.spec.in: require libpcap[-devel] if qemu is built * src/internal.h: add the new ATTRIBUTE_PACKED define * src/Makefile.am src/libvirt_private.syms: add the new modules and symbols * src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added * src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch] src/nwfilter/nwfilter_ebiptables_driver.[ch] src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in * tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
virNWFilterUnlockFilterUpdates;
# nwfilter_params.h
virNWFilterHashTableCreate;
virNWFilterHashTableFree;
virNWFilterHashTablePut;
virNWFilterHashTablePutAll;
virNWFilterHashTableRemoveEntry;
# pci.h
pciDettachDevice;
pciDeviceFileIterate;
pciDeviceGetManaged;
pciDeviceIsAssignable;
pciDeviceIsVirtualFunction;
pciDeviceListAdd;
pciDeviceListCount;
pciDeviceListDel;
pciDeviceListFree;
pciDeviceListGet;
pciDeviceListNew;
pciDeviceListSteal;
pciDeviceNetName;
pciDeviceReAttachInit;
pciDeviceSetManaged;
pciFreeDevice;
pciGetDevice;
pciGetPhysicalFunction;
pciGetVirtualFunctionIndex;
pciGetVirtualFunctions;
pciReAttachDevice;
pciResetDevice;
pciWaitForDeviceCleanup;
# processinfo.h
virProcessInfoGetAffinity;
virProcessInfoSetAffinity;
# qparams.h
free_qparam_set;
qparam_get_query;
qparam_query_parse;
# secret_conf.h
virSecretDefFormat;
virSecretDefFree;
virSecretDefParseFile;
virSecretDefParseString;
Refactor the security drivers to simplify usage The current security driver usage requires horrible code like if (driver->securityDriver && driver->securityDriver->domainSetSecurityHostdevLabel && driver->securityDriver->domainSetSecurityHostdevLabel(driver->securityDriver, vm, hostdev) < 0) This pair of checks for NULL clutters up the code, making the driver calls 2 lines longer than they really need to be. The goal of the patchset is to change the calling convention to simply if (virSecurityManagerSetHostdevLabel(driver->securityDriver, vm, hostdev) < 0) The first check for 'driver->securityDriver' being NULL is removed by introducing a 'no op' security driver that will always be present if no real driver is enabled. This guarentees driver->securityDriver != NULL. The second check for 'driver->securityDriver->domainSetSecurityHostdevLabel' being non-NULL is hidden in a new abstraction called virSecurityManager. This separates the driver callbacks, from main internal API. The addition of a virSecurityManager object, that is separate from the virSecurityDriver struct also allows for security drivers to carry state / configuration information directly. Thus the DAC/Stack drivers from src/qemu which used to pull config from 'struct qemud_driver' can now be moved into the 'src/security' directory and store their config directly. * src/qemu/qemu_conf.h, src/qemu/qemu_driver.c: Update to use new virSecurityManager APIs * src/qemu/qemu_security_dac.c, src/qemu/qemu_security_dac.h src/qemu/qemu_security_stacked.c, src/qemu/qemu_security_stacked.h: Move into src/security directory * src/security/security_stack.c, src/security/security_stack.h, src/security/security_dac.c, src/security/security_dac.h: Generic versions of previous QEMU specific drivers * src/security/security_apparmor.c, src/security/security_apparmor.h, src/security/security_driver.c, src/security/security_driver.h, src/security/security_selinux.c, src/security/security_selinux.h: Update to take virSecurityManagerPtr object as the first param in all callbacks * src/security/security_nop.c, src/security/security_nop.h: Stub implementation of all security driver APIs. * src/security/security_manager.h, src/security/security_manager.c: New internal API for invoking security drivers * src/libvirt.c: Add missing debug for security APIs
2010-11-17 20:26:30 +00:00
# security_driver.h
virSecurityDriverLookup;
# security_manager.h
virSecurityManagerClearSocketLabel;
virSecurityManagerFree;
virSecurityManagerGenLabel;
virSecurityManagerGetDOI;
virSecurityManagerGetModel;
virSecurityManagerGetProcessLabel;
virSecurityManagerNew;
virSecurityManagerNewStack;
virSecurityManagerNewDAC;
virSecurityManagerReleaseLabel;
virSecurityManagerReserveLabel;
virSecurityManagerRestoreImageLabel;
virSecurityManagerRestoreAllLabel;
virSecurityManagerRestoreHostdevLabel;
virSecurityManagerRestoreSavedStateLabel;
virSecurityManagerSetAllLabel;
virSecurityManagerSetDaemonSocketLabel;
virSecurityManagerSetImageFDLabel;
Refactor the security drivers to simplify usage The current security driver usage requires horrible code like if (driver->securityDriver && driver->securityDriver->domainSetSecurityHostdevLabel && driver->securityDriver->domainSetSecurityHostdevLabel(driver->securityDriver, vm, hostdev) < 0) This pair of checks for NULL clutters up the code, making the driver calls 2 lines longer than they really need to be. The goal of the patchset is to change the calling convention to simply if (virSecurityManagerSetHostdevLabel(driver->securityDriver, vm, hostdev) < 0) The first check for 'driver->securityDriver' being NULL is removed by introducing a 'no op' security driver that will always be present if no real driver is enabled. This guarentees driver->securityDriver != NULL. The second check for 'driver->securityDriver->domainSetSecurityHostdevLabel' being non-NULL is hidden in a new abstraction called virSecurityManager. This separates the driver callbacks, from main internal API. The addition of a virSecurityManager object, that is separate from the virSecurityDriver struct also allows for security drivers to carry state / configuration information directly. Thus the DAC/Stack drivers from src/qemu which used to pull config from 'struct qemud_driver' can now be moved into the 'src/security' directory and store their config directly. * src/qemu/qemu_conf.h, src/qemu/qemu_driver.c: Update to use new virSecurityManager APIs * src/qemu/qemu_security_dac.c, src/qemu/qemu_security_dac.h src/qemu/qemu_security_stacked.c, src/qemu/qemu_security_stacked.h: Move into src/security directory * src/security/security_stack.c, src/security/security_stack.h, src/security/security_dac.c, src/security/security_dac.h: Generic versions of previous QEMU specific drivers * src/security/security_apparmor.c, src/security/security_apparmor.h, src/security/security_driver.c, src/security/security_driver.h, src/security/security_selinux.c, src/security/security_selinux.h: Update to take virSecurityManagerPtr object as the first param in all callbacks * src/security/security_nop.c, src/security/security_nop.h: Stub implementation of all security driver APIs. * src/security/security_manager.h, src/security/security_manager.c: New internal API for invoking security drivers * src/libvirt.c: Add missing debug for security APIs
2010-11-17 20:26:30 +00:00
virSecurityManagerSetImageLabel;
virSecurityManagerSetHostdevLabel;
virSecurityManagerSetProcessLabel;
virSecurityManagerSetSavedStateLabel;
virSecurityManagerSetSocketLabel;
Refactor the security drivers to simplify usage The current security driver usage requires horrible code like if (driver->securityDriver && driver->securityDriver->domainSetSecurityHostdevLabel && driver->securityDriver->domainSetSecurityHostdevLabel(driver->securityDriver, vm, hostdev) < 0) This pair of checks for NULL clutters up the code, making the driver calls 2 lines longer than they really need to be. The goal of the patchset is to change the calling convention to simply if (virSecurityManagerSetHostdevLabel(driver->securityDriver, vm, hostdev) < 0) The first check for 'driver->securityDriver' being NULL is removed by introducing a 'no op' security driver that will always be present if no real driver is enabled. This guarentees driver->securityDriver != NULL. The second check for 'driver->securityDriver->domainSetSecurityHostdevLabel' being non-NULL is hidden in a new abstraction called virSecurityManager. This separates the driver callbacks, from main internal API. The addition of a virSecurityManager object, that is separate from the virSecurityDriver struct also allows for security drivers to carry state / configuration information directly. Thus the DAC/Stack drivers from src/qemu which used to pull config from 'struct qemud_driver' can now be moved into the 'src/security' directory and store their config directly. * src/qemu/qemu_conf.h, src/qemu/qemu_driver.c: Update to use new virSecurityManager APIs * src/qemu/qemu_security_dac.c, src/qemu/qemu_security_dac.h src/qemu/qemu_security_stacked.c, src/qemu/qemu_security_stacked.h: Move into src/security directory * src/security/security_stack.c, src/security/security_stack.h, src/security/security_dac.c, src/security/security_dac.h: Generic versions of previous QEMU specific drivers * src/security/security_apparmor.c, src/security/security_apparmor.h, src/security/security_driver.c, src/security/security_driver.h, src/security/security_selinux.c, src/security/security_selinux.h: Update to take virSecurityManagerPtr object as the first param in all callbacks * src/security/security_nop.c, src/security/security_nop.h: Stub implementation of all security driver APIs. * src/security/security_manager.h, src/security/security_manager.c: New internal API for invoking security drivers * src/libvirt.c: Add missing debug for security APIs
2010-11-17 20:26:30 +00:00
virSecurityManagerVerify;
# sexpr.h
sexpr_append;
sexpr_cons;
sexpr_float;
sexpr_fmt_node;
sexpr_free;
sexpr_has;
sexpr_int;
sexpr_lookup;
sexpr_nil;
sexpr_node;
sexpr_node_copy;
sexpr_string;
sexpr_u64;
sexpr2string;
string2sexpr;
# storage_conf.h
virStoragePartedFsTypeTypeToString;
virStoragePoolDefFormat;
virStoragePoolDefFree;
virStoragePoolDefParseFile;
virStoragePoolDefParseNode;
virStoragePoolDefParseSourceString;
virStoragePoolDefParseString;
virStoragePoolFormatDiskTypeToString;
virStoragePoolFormatFileSystemNetTypeToString;
virStoragePoolFormatFileSystemTypeToString;
virStoragePoolLoadAllConfigs;
virStoragePoolObjAssignDef;
virStoragePoolObjClearVols;
virStoragePoolObjDeleteDef;
virStoragePoolObjFindByName;
virStoragePoolObjFindByUUID;
virStoragePoolSourceFindDuplicateDevices;
virStoragePoolObjIsDuplicate;
virStoragePoolSourceFindDuplicate;
virStoragePoolObjListFree;
virStoragePoolObjLock;
virStoragePoolObjRemove;
virStoragePoolObjSaveDef;
virStoragePoolObjUnlock;
virStoragePoolSourceFree;
virStoragePoolSourceListFormat;
virStoragePoolSourceListNewSource;
virStoragePoolTypeFromString;
virStorageVolDefFindByKey;
virStorageVolDefFindByName;
virStorageVolDefFindByPath;
virStorageVolDefFormat;
virStorageVolDefFree;
virStorageVolDefParseFile;
virStorageVolDefParseNode;
virStorageVolDefParseString;
# storage_encryption_conf.h
virStorageEncryptionFormat;
virStorageEncryptionFree;
virStorageEncryptionParseNode;
virStorageGenerateQcowPassphrase;
# storage_file.h
virStorageFileFormatTypeFromString;
virStorageFileFormatTypeToString;
virStorageFileFreeMetadata;
virStorageFileGetMetadata;
virStorageFileGetMetadataFromFD;
virStorageFileIsSharedFS;
virStorageFileIsSharedFSType;
virStorageFileProbeFormat;
virStorageFileProbeFormatFromFD;
# sysinfo.h
virSysinfoDefFree;
virSysinfoFormat;
virSysinfoRead;
# threadpool.h
virThreadPoolFree;
virThreadPoolNew;
virThreadPoolSendJob;
2009-01-15 19:56:05 +00:00
# threads.h
virCondBroadcast;
virCondDestroy;
virCondInit;
virCondSignal;
virCondWait;
virCondWaitUntil;
virMutexDestroy;
2009-01-15 19:56:05 +00:00
virMutexInit;
virMutexInitRecursive;
2009-01-15 19:56:05 +00:00
virMutexLock;
virMutexUnlock;
virOnce;
virThreadCreate;
virThreadID;
virThreadIsSelf;
virThreadJoin;
virThreadSelf;
virThreadSelfID;
2009-01-15 19:56:05 +00:00
# usb.h
usbDeviceFileIterate;
usbDeviceGetBus;
usbDeviceGetDevno;
usbFindDevice;
usbFreeDevice;
usbGetDevice;
2009-01-15 19:56:05 +00:00
# util.h
saferead;
safewrite;
safezero;
virArgvToString;
virAsprintf;
virBuildPathInternal;
virDirCreate;
virEmitXMLWarning;
virEnumFromString;
virEnumToString;
virEventAddHandle;
virEventRemoveHandle;
virFileAbsPath;
virFileBuildPath;
virFileExists;
virFileFindMountPoint;
virFileHasSuffix;
virFileIsExecutable;
virFileIsLink;
virFileLinkPointsTo;
virFileLock;
virFileMakePath;
virFileMatchesNameSuffix;
virFileOpenAs;
virFileOpenTty;
virFileReadAll;
virFileReadLimFD;
virFileResolveLink;
virFileSanitizePath;
virFileStripSuffix;
virFileUnlock;
virFileWaitForDevices;
virFileWriteStr;
virFindFileInPath;
virFormatMacAddr;
Give each virtual network bridge its own fixed MAC address This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463 The problem was that, since a bridge always acquires the MAC address of the connected interface with the numerically lowest MAC, as guests are started and stopped, it was possible for the MAC address to change over time, and this change in the network was being detected by Windows 7 (it sees the MAC of the default route change), so on each reboot it would bring up a dialog box asking about this "new network". The solution is to create a dummy tap interface with a MAC guaranteed to be lower than any guest interface's MAC, and attach that tap to the bridge as soon as it's created. Since all guest MAC addresses start with 0xFE, we can just generate a MAC with the standard "0x52, 0x54, 0" prefix, and it's guaranteed to always win (physical interfaces are never connected to these bridges, so we don't need to worry about competing numerically with them). Note that the dummy tap is never set to IFF_UP state - that's not necessary in order for the bridge to take its MAC, and not setting it to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed in the output of the ifconfig command. I chose to not auto-generate the MAC address in the network XML parser, as there are likely to be consumers of that API that don't need or want to have a MAC address associated with the bridge. Instead, in bridge_driver.c when the network is being defined, if there is no MAC, one is generated. To account for virtual network configs that already exist when upgrading from an older version of libvirt, I've added a %post script to the specfile that searches for all network definitions in both the config directory (/etc/libvirt/qemu/networks) and the state directory (/var/lib/libvirt/network) that are missing a mac address, generates a random address, and adds it to the config (and a matching address to the state file, if there is one). docs/formatnetwork.html.in: document <mac address.../> docs/schemas/network.rng: add nac address to schema libvirt.spec.in: %post script to update existing networks src/conf/network_conf.[ch]: parse and format <mac address.../> src/libvirt_private.syms: export a couple private symbols we need src/network/bridge_driver.c: auto-generate mac address when needed, create dummy interface if mac address is present. tests/networkxml2xmlin/isolated-network.xml tests/networkxml2xmlin/routed-network.xml tests/networkxml2xmlout/isolated-network.xml tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
2011-02-09 08:28:12 +00:00
virGenerateMacAddr;
virGetGroupID;
virGetHostname;
virGetUserDirectory;
virGetUserID;
virGetUserName;
virHexToBin;
virIndexToDiskName;
virIsDevMapperDevice;
virKillProcess;
virMacAddrCompare;
virParseMacAddr;
virParseNumber;
virParseVersionString;
virPipeReadUntilEOF;
virRandom;
virRandomInitialize;
virSetBlocking;
virSetCloseExec;
virSetInherit;
virSetNonBlock;
virSetUIDGID;
virSkipSpaces;
virSkipSpacesAndBackslash;
virSkipSpacesBackwards;
virStrToDouble;
virStrToLong_i;
virStrToLong_l;
virStrToLong_ll;
virStrToLong_ui;
virStrToLong_ul;
virStrToLong_ull;
virStrcpy;
virStrncpy;
virTimeMs;
virTimestamp;
virTrimSpaces;
virVasprintf;
# uuid.h
virGetHostUUID;
virSetHostUUIDStr;
virUUIDFormat;
virUUIDGenerate;
virUUIDParse;
# viraudit.h
virAuditClose;
virAuditEncode;
virAuditLog;
virAuditOpen;
virAuditSend;
# virfile.h
virFileClose;
virFileDirectFdClose;
virFileDirectFdFlag;
virFileDirectFdFree;
virFileDirectFdNew;
virFileFclose;
virFileFdopen;
# virpidfile.h
virPidFileAcquire;
virPidFileAcquirePath;
virPidFileBuildPath;
virPidFileRead;
virPidFileReadIfAlive;
virPidFileReadPath;
virPidFileReadPathIfAlive;
virPidFileRelease;
virPidFileReleasePath;
virPidFileWrite;
virPidFileWritePath;
virPidFileDelete;
virPidFileDeletePath;
# virterror_internal.h
virDispatchError;
virErrorMsg;
virRaiseErrorFull;
virReportErrorHelper;
virReportOOMErrorFull;
virReportSystemErrorFull;
virSetError;
virSetErrorLogPriorityFunc;
virStrerror;
# virkeycode.h
virKeycodeSetTypeToString;
virKeycodeSetTypeFromString;
virKeycodeValueFromString;
virKeycodeValueTranslate;
# xml.h
virXMLParseHelper;
virXMLPropString;
virXPathBoolean;
virXPathInt;
virXPathLong;
virXPathLongHex;
virXPathLongLong;
virXPathNode;
virXPathNodeSet;
virXPathNumber;
virXPathString;
virXPathStringLimit;
virXPathUInt;
virXPathULong;
virXPathULongHex;
virXPathULongLong;