libvirt/src/libvirt_private.syms

1878 lines
41 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.
#
# bitmap.h
virBitmapClearAll;
virBitmapClearBit;
virBitmapCopy;
virBitmapCountBits;
virBitmapEqual;
virBitmapFormat;
virBitmapFree;
virBitmapGetBit;
virBitmapIsAllSet;
virBitmapNew;
virBitmapNewCopy;
virBitmapNewData;
virBitmapNextSetBit;
virBitmapParse;
virBitmapSetAll;
virBitmapSetBit;
virBitmapSize;
virBitmapString;
virBitmapToData;
# buf.h
virBufferAdd;
virBufferAddChar;
virBufferAdjustIndent;
virBufferAsprintf;
virBufferContentAndReset;
virBufferCurrentContent;
virBufferError;
virBufferEscape;
virBufferEscapeSexpr;
virBufferEscapeShell;
virBufferEscapeString;
virBufferFreeAndReset;
virBufferGetIndent;
virBufferStrcat;
virBufferTrim;
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;
virCgroupAddTaskController;
virCgroupAllowDevice;
virCgroupAllowDeviceMajor;
virCgroupAllowDevicePath;
virCgroupControllerTypeFromString;
virCgroupControllerTypeToString;
virCgroupDenyAllDevices;
virCgroupDenyDevice;
virCgroupDenyDeviceMajor;
virCgroupDenyDevicePath;
virCgroupForDomain;
virCgroupForDriver;
virCgroupGetAppRoot;
virCgroupForEmulator;
virCgroupForVcpu;
virCgroupFree;
virCgroupGetBlkioWeight;
virCgroupGetCpuCfsPeriod;
virCgroupGetCpuCfsQuota;
virCgroupGetCpuShares;
virCgroupGetCpuacctPercpuUsage;
virCgroupGetCpuacctStat;
virCgroupGetCpuacctUsage;
virCgroupGetCpusetCpus;
virCgroupGetCpusetMems;
virCgroupGetFreezerState;
virCgroupGetMemSwapUsage;
virCgroupGetMemSwapHardLimit;
virCgroupGetMemoryHardLimit;
virCgroupGetMemorySoftLimit;
virCgroupGetMemoryUsage;
virCgroupKill;
virCgroupKillPainfully;
virCgroupKillRecursive;
virCgroupMounted;
virCgroupMoveTask;
virCgroupPathOfController;
virCgroupRemove;
virCgroupSetBlkioDeviceWeight;
virCgroupSetBlkioWeight;
virCgroupSetCpuCfsPeriod;
virCgroupSetCpuCfsQuota;
virCgroupSetCpuShares;
virCgroupSetCpusetCpus;
virCgroupSetCpusetMems;
virCgroupSetFreezerState;
virCgroupSetMemSwapHardLimit;
virCgroupSetMemory;
virCgroupSetMemoryHardLimit;
virCgroupSetMemorySoftLimit;
# command.h
virCommandAbort;
virCommandAddArg;
virCommandAddArgBuffer;
virCommandAddArgFormat;
virCommandAddArgList;
virCommandAddArgPair;
virCommandAddArgSet;
virCommandAddEnvBuffer;
virCommandAddEnvFormat;
virCommandAddEnvPair;
virCommandAddEnvPass;
virCommandAddEnvPassCommon;
virCommandAddEnvString;
virCommandAllowCap;
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;
virCommandWait;
virCommandWriteArgLog;
virFork;
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;
virCPUDefCopyModel;
virCPUDefFormat;
virCPUDefFormatBuf;
virCPUDefFree;
virCPUDefFreeModel;
virCPUDefParseXML;
virCPUModeTypeToString;
# datatypes.h
virConnectClass;
virDomainClass;
virDomainSnapshotClass;
virGetConnect;
virGetDomain;
virGetDomainSnapshot;
virGetInterface;
virGetNWFilter;
virGetNetwork;
virGetNodeDevice;
virGetSecret;
virGetStoragePool;
virGetStorageVol;
virGetStream;
virInterfaceClass;
virNetworkClass;
virNodeDeviceClass;
virNWFilterClass;
virSecretClass;
virStoragePoolClass;
virStorageVolClass;
virStreamClass;
# device_conf.h
virDeviceAddressPciMultiTypeFromString;
virDeviceAddressPciMultiTypeToString;
virDevicePCIAddressEqual;
virDevicePCIAddressFormat;
virDevicePCIAddressIsValid;
virDevicePCIAddressParseXML;
# dnsmasq.h
dnsmasqAddDhcpHost;
dnsmasqAddHost;
dnsmasqCapsGet;
dnsmasqCapsGetBinaryPath;
dnsmasqCapsGetVersion;
dnsmasqCapsNewFromBuffer;
dnsmasqCapsNewFromFile;
dnsmasqCapsNewFromBinary;
dnsmasqCapsRefresh;
dnsmasqContextFree;
dnsmasqContextNew;
dnsmasqDelete;
dnsmasqReload;
dnsmasqSave;
# domain_audit.h
virDomainAuditCgroup;
virDomainAuditCgroupMajor;
virDomainAuditCgroupPath;
virDomainAuditDisk;
virDomainAuditFS;
virDomainAuditHostdev;
virDomainAuditInit;
virDomainAuditMemory;
virDomainAuditNet;
virDomainAuditNetDevice;
virDomainAuditRedirdev;
virDomainAuditSecurityLabel;
virDomainAuditStart;
virDomainAuditStop;
virDomainAuditVcpu;
# domain_conf.h
virBlkioDeviceWeightArrayClear;
virDiskNameToBusDeviceIndex;
virDiskNameToIndex;
virDomainActualNetDefFree;
virDomainAssignDef;
virDomainBlockedReasonTypeFromString;
virDomainBlockedReasonTypeToString;
virDomainBootMenuTypeFromString;
virDomainBootMenuTypeToString;
virDomainChrConsoleTargetTypeFromString;
virDomainChrConsoleTargetTypeToString;
virDomainChrDefForeach;
virDomainChrDefFree;
virDomainChrDefNew;
virDomainChrSourceDefCopy;
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;
virDomainClockBasisTypeToString;
virDomainClockOffsetTypeFromString;
virDomainClockOffsetTypeToString;
virDomainConfigFile;
virDomainControllerDefFree;
virDomainControllerFind;
virDomainControllerInsert;
virDomainControllerInsertPreAlloced;
virDomainControllerModelSCSITypeFromString;
virDomainControllerModelSCSITypeToString;
virDomainControllerModelUSBTypeFromString;
virDomainControllerModelUSBTypeToString;
virDomainControllerRemove;
virDomainControllerTypeToString;
virDomainCpuPlacementModeTypeFromString;
virDomainCpuPlacementModeTypeToString;
virDomainDefAddImplicitControllers;
virDomainDefCheckABIStability;
virDomainDefClearDeviceAliases;
virDomainDefClearPCIAddresses;
virDomainDefCompatibleDevice;
virDomainDefCopy;
virDomainDefFormat;
virDomainDefFormatInternal;
virDomainDefFree;
virDomainDefGetSecurityLabelDef;
virDomainDiskDefGetSecurityLabelDef;
virDomainDefAddSecurityLabelDef;
virDomainDefParseFile;
virDomainDefParseNode;
virDomainDefParseString;
virDomainDeleteConfig;
virDomainDeviceAddressIsValid;
virDomainDeviceAddressTypeToString;
virDomainDeviceDefCopy;
virDomainDeviceDefFree;
virDomainDeviceDefParse;
virDomainDeviceInfoCopy;
virDomainDeviceInfoIterate;
virDomainDeviceTypeToString;
virDomainDiskBusTypeToString;
virDomainDiskCacheTypeFromString;
virDomainDiskCacheTypeToString;
virDomainDiskCopyOnReadTypeFromString;
virDomainDiskCopyOnReadTypeToString;
virDomainDiskDefAssignAddress;
virDomainDiskDefForeachPath;
virDomainDiskDefFree;
virDomainDiskDeviceTypeToString;
virDomainDiskErrorPolicyTypeFromString;
virDomainDiskErrorPolicyTypeToString;
virDomainDiskFindControllerModel;
virDomainDiskGeometryTransTypeFromString;
virDomainDiskGeometryTransTypeToString;
virDomainDiskHostDefFree;
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;
virDomainDiskProtocolTransportTypeFromString;
virDomainDiskProtocolTransportTypeToString;
virDomainDiskRemove;
virDomainDiskRemoveByName;
virDomainDiskTypeFromString;
virDomainDiskTypeToString;
virDomainEmulatorPinAdd;
virDomainEmulatorPinDel;
virDomainFSDefFree;
virDomainFSIndexByName;
virDomainFSTypeFromString;
virDomainFSTypeToString;
virDomainFSWrpolicyTypeFromString;
virDomainFSWrpolicyTypeToString;
virDomainFeatureStateTypeFromString;
virDomainFeatureStateTypeToString;
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;
virDomainGraphicsSpiceMouseModeTypeFromString;
virDomainGraphicsSpiceMouseModeTypeToString;
virDomainGraphicsSpicePlaybackCompressionTypeFromString;
virDomainGraphicsSpicePlaybackCompressionTypeToString;
virDomainGraphicsSpiceStreamingModeTypeFromString;
virDomainGraphicsSpiceStreamingModeTypeToString;
virDomainGraphicsSpiceZlibCompressionTypeFromString;
virDomainGraphicsSpiceZlibCompressionTypeToString;
virDomainGraphicsTypeFromString;
virDomainGraphicsTypeToString;
blockjob: react to active block copy For now, disk migration via block copy job is not implemented in libvirt. But when we do implement it, we have to deal with the fact that qemu does not yet provide an easy way to re-start a qemu process with mirroring still intact. Paolo has proposed an idea for a persistent dirty bitmap that might make this possible, but until that design is complete, it's hard to say what changes libvirt would need. Even something like 'virDomainSave' becomes hairy, if you realize the implications that 'virDomainRestore' would be stuck with recreating the same mirror layout. But if we step back and look at the bigger picture, we realize that the initial client of live storage migration via disk mirroring is oVirt, which always uses transient domains, and that if a transient domain is destroyed while a mirror exists, oVirt can easily restart the storage migration by creating a new domain that visits just the source storage, with no loss in data. We can make life a lot easier by being cowards for now, forbidding certain operations on a domain. This patch guarantees that we never get in a state where we would have to restart a domain with a mirroring block copy, by preventing saves, snapshots, migration, hot unplug of a disk in use, and conversion to a persistent domain (thankfully, it is still relatively easy to 'virsh undefine' a running domain to temporarily make it transient, run tests on 'virsh blockcopy', then 'virsh define' to restore the persistence). Later, if the qemu design is enhanced, we can relax our code. The change to qemudDomainDefine looks a bit odd for undoing an assignment, rather than probing up front to avoid the assignment, but this is because of how virDomainAssignDef combines both a lookup and assignment into a single function call. * src/conf/domain_conf.h (virDomainHasDiskMirror): New prototype. * src/conf/domain_conf.c (virDomainHasDiskMirror): New function. * src/libvirt_private.syms (domain_conf.h): Export it. * src/qemu/qemu_driver.c (qemuDomainSaveInternal) (qemuDomainSnapshotCreateXML, qemuDomainRevertToSnapshot) (qemuDomainBlockJobImpl, qemudDomainDefine): Prevent dangerous actions while block copy is already in action. * src/qemu/qemu_hotplug.c (qemuDomainDetachDiskDevice): Likewise. * src/qemu/qemu_migration.c (qemuMigrationIsAllowed): Likewise.
2012-04-10 02:39:47 +00:00
virDomainHasDiskMirror;
virDomainHostdevDefAlloc;
virDomainHostdevDefClear;
2009-04-24 12:19:00 +00:00
virDomainHostdevDefFree;
virDomainHostdevFind;
virDomainHostdevInsert;
virDomainHostdevModeTypeToString;
virDomainHostdevRemove;
virDomainHostdevSubsysTypeToString;
virDomainHubTypeFromString;
virDomainHubTypeToString;
virDomainHypervTypeFromString;
virDomainHypervTypeToString;
virDomainInputDefFree;
virDomainIoEventFdTypeFromString;
virDomainIoEventFdTypeToString;
virDomainLeaseDefFree;
virDomainLeaseIndex;
virDomainLeaseInsert;
virDomainLeaseInsertPreAlloc;
virDomainLeaseInsertPreAlloced;
virDomainLeaseRemove;
virDomainLeaseRemoveAt;
virDomainLifecycleCrashTypeFromString;
virDomainLifecycleCrashTypeToString;
virDomainLifecycleTypeFromString;
virDomainLifecycleTypeToString;
virDomainList;
virDomainLiveConfigHelperMethod;
virDomainLoadAllConfigs;
virDomainLockFailureTypeFromString;
virDomainLockFailureTypeToString;
virDomainLookupVcpuPin;
virDomainMemballoonModelTypeFromString;
virDomainMemballoonModelTypeToString;
virDomainMemDumpTypeFromString;
virDomainMemDumpTypeToString;
virDomainNetDefFree;
virDomainNetFind;
qemu: fix attach/detach of netdevs with matching mac addrs This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=862515 which describes inconsistencies in dealing with duplicate mac addresses on network devices in a domain. (at any rate, it resolves *almost* everything, and prints out an informative error message for the one problem that isn't solved, but has a workaround.) A synopsis of the problems: 1) you can't do a persistent attach-interface of a device with a mac address that matches an existing device. 2) you *can* do a live attach-interface of such a device. 3) you *can* directly edit a domain and put in two devices with matching mac addresses. 4) When running virsh detach-device (live or config), only MAC address is checked when matching the device to remove, so the first device with the desired mac address will be removed. This isn't always the one that's wanted. 5) when running virsh detach-interface (live or config), the only two items that can be specified to match against are mac address and model type (virtio, etc) - if multiple netdevs match both of those attributes, it again just finds the first one added and assumes that is the only match. Since it is completely valid to have multiple network devices with the same MAC address (although it can cause problems in many cases, there *are* valid use cases), what is needed is: 1) remove the restriction that prohibits doing a persistent add of a netdev with a duplicate mac address. 2) enhance the backend of virDomainDetachDeviceFlags to check for something that *is* guaranteed unique (but still work with just mac address, as long as it yields only a single results. This patch does three things: 1) removes the check for duplicate mac address during a persistent netdev attach. 2) unifies the searching for both live and config detach of netdevices in the subordinate functions of qemuDomainModifyDeviceFlags() to use the new function virDomainNetFindIdx (which matches mac address and PCI address if available, checking for duplicates if only mac address was specified). This function returns -2 if multiple matches are found, allowing the callers to print out an appropriate message. Steps 1 & 2 are enough to fully fix the problem when using virsh attach-device and detach-device (which require an XML description of the device rather than a bunch of commandline args) 3) modifies the virsh detach-interface command to check for multiple matches of mac address and show an error message suggesting use of the detach-device command in cases where there are multiple matching mac addresses. Later we should decide how we want to input a PCI address on the virsh commandline, and enhance detach-interface to take a --address option, eliminating the need to use detach-device * src/conf/domain_conf.c * src/conf/domain_conf.h * src/libvirt_private.syms * added new virDomainNetFindIdx function * removed now unused virDomainNetIndexByMac and virDomainNetRemoveByMac * src/qemu/qemu_driver.c * remove check for duplicate max from qemuDomainAttachDeviceConfig * use virDomainNetFindIdx/virDomainNetRemove instead of virDomainNetRemoveByMac in qemuDomainDetachDeviceConfig * use virDomainNetFindIdx instead of virDomainIndexByMac in qemuDomainUpdateDeviceConfig * src/qemu/qemu_hotplug.c * use virDomainNetFindIdx instead of a homespun loop in qemuDomainDetachNetDevice. * tools/virsh-domain.c: modified detach-interface command as described above
2012-10-25 20:03:35 +00:00
virDomainNetFindIdx;
virDomainNetGetActualBandwidth;
virDomainNetGetActualBridgeName;
virDomainNetGetActualDirectDev;
virDomainNetGetActualDirectMode;
conf: parse/format type='hostdev' network interfaces This is the new interface type that sets up an SR-IOV PCI network device to be assigned to the guest with PCI passthrough after initializing some network device-specific things from the config (e.g. MAC address, virtualport profile parameters). Here is an example of the syntax: <interface type='hostdev' managed='yes'> <source> <address type='pci' domain='0' bus='0' slot='4' function='3'/> </source> <mac address='00:11:22:33:44:55'/> <address type='pci' domain='0' bus='0' slot='7' function='0'/> </interface> This would assign the PCI card from bus 0 slot 4 function 3 on the host, to bus 0 slot 7 function 0 on the guest, but would first set the MAC address of the card to 00:11:22:33:44:55. NB: The parser and formatter don't care if the PCI card being specified is a standard single function network adapter, or a virtual function (VF) of an SR-IOV capable network adapter, but the upcoming code that implements the back end of this config will work *only* with SR-IOV VFs. This is because modifying the mac address of a standard network adapter prior to assigning it to a guest is pointless - part of the device reset that occurs during that process will reset the MAC address to the value programmed into the card's firmware. Although it's not supported by any of libvirt's hypervisor drivers, usb network hostdevs are also supported in the parser and formatter for completeness and consistency. <source> syntax is identical to that for plain <hostdev> devices, except that the <address> element should have "type='usb'" added if bus/device are specified: <interface type='hostdev'> <source> <address type='usb' bus='0' device='4'/> </source> <mac address='00:11:22:33:44:55'/> </interface> If the vendor/product form of usb specification is used, type='usb' is implied: <interface type='hostdev'> <source> <vendor id='0x0012'/> <product id='0x24dd'/> </source> <mac address='00:11:22:33:44:55'/> </interface> Again, the upcoming patch to fill in the backend of this functionality will log an error and fail with "Unsupported Config" if you actually try to assign a USB network adapter to a guest using <interface type='hostdev'> - just use a standard <hostdev> entry in that case (and also for single-port PCI adapters).
2012-02-15 17:37:15 +00:00
virDomainNetGetActualHostdev;
virDomainNetGetActualType;
virDomainNetGetActualVirtPortProfile;
conf: add <vlan> element to network and domain interface elements The following config elements now support a <vlan> subelements: within a domain: <interface>, and the <actual> subelement of <interface> within a network: the toplevel, as well as any <portgroup> Each vlan element must have one or more <tag id='n'/> subelements. If there is more than one tag, it is assumed that vlan trunking is being requested. If trunking is required with only a single tag, the attribute "trunk='yes'" should be added to the toplevel <vlan> element. Some examples: <interface type='hostdev'/> <vlan> <tag id='42'/> </vlan> <mac address='52:54:00:12:34:56'/> ... </interface> <network> <name>vlan-net</name> <vlan trunk='yes'> <tag id='30'/> </vlan> <virtualport type='openvswitch'/> </network> <interface type='network'/> <source network='vlan-net'/> ... </interface> <network> <name>trunk-vlan</name> <vlan> <tag id='42'/> <tag id='43'/> </vlan> ... </network> <network> <name>multi</name> ... <portgroup name='production'/> <vlan> <tag id='42'/> </vlan> </portgroup> <portgroup name='test'/> <vlan> <tag id='666'/> </vlan> </portgroup> </network> <interface type='network'/> <source network='multi' portgroup='test'/> ... </interface> IMPORTANT NOTE: As of this patch there is no backend support for the vlan element for *any* network device type. When support is added in later patches, it will only be for those select network types that support setting up a vlan on the host side, without the guest's involvement. (For example, it will be possible to configure a vlan for a guest connected to an openvswitch bridge, but it won't be possible to do that for one that is connected to a standard Linux host bridge.)
2012-08-12 07:51:30 +00:00
virDomainNetGetActualVlan;
virDomainNetInsert;
virDomainNetRemove;
virDomainNetTypeToString;
virDomainNostateReasonTypeFromString;
virDomainNostateReasonTypeToString;
virDomainNumatuneMemModeTypeFromString;
virDomainNumatuneMemModeTypeToString;
numad: Set memory policy from numad advisory nodeset Though numad will manage the memory allocation of task dynamically, it wants management application (libvirt) to pre-set the memory policy according to the advisory nodeset returned from querying numad, (just like pre-bind CPU nodeset for domain process), and thus the performance could benefit much more from it. This patch introduces new XML tag 'placement', value 'auto' indicates whether to set the memory policy with the advisory nodeset from numad, and its value defaults to the value of <vcpu> placement, or 'static' if 'nodeset' is specified. Example of the new XML tag's usage: <numatune> <memory placement='auto' mode='interleave'/> </numatune> Just like what current "numatune" does, the 'auto' numa memory policy setting uses libnuma's API too. If <vcpu> "placement" is "auto", and <numatune> is not specified explicitly, a default <numatume> will be added with "placement" set as "auto", and "mode" set as "strict". The following XML can now fully drive numad: 1) <vcpu> placement is 'auto', no <numatune> is specified. <vcpu placement='auto'>10</vcpu> 2) <vcpu> placement is 'auto', no 'placement' is specified for <numatune>. <vcpu placement='auto'>10</vcpu> <numatune> <memory mode='interleave'/> </numatune> And it's also able to control the CPU placement and memory policy independently. e.g. 1) <vcpu> placement is 'auto', and <numatune> placement is 'static' <vcpu placement='auto'>10</vcpu> <numatune> <memory mode='strict' nodeset='0-10,^7'/> </numatune> 2) <vcpu> placement is 'static', and <numatune> placement is 'auto' <vcpu placement='static' cpuset='0-24,^12'>10</vcpu> <numatune> <memory mode='interleave' placement='auto'/> </numatume> A follow up patch will change the XML formatting codes to always output 'placement' for <vcpu>, even it's 'static'.
2012-05-08 16:04:34 +00:00
virDomainNumatuneMemPlacementModeTypeFromString;
virDomainNumatuneMemPlacementModeTypeToString;
virDomainObjAssignDef;
virDomainObjCopyPersistentDef;
virDomainObjGetPersistentDef;
virDomainObjGetState;
virDomainObjIsDuplicate;
virDomainObjListDeinit;
virDomainObjListGetActiveIDs;
virDomainObjListGetInactiveNames;
virDomainObjListInit;
virDomainObjListNumOfDomains;
virDomainObjLock;
virDomainObjNew;
virDomainObjSetDefTransient;
virDomainObjSetState;
virDomainObjTaint;
virDomainObjUnlock;
virDomainPausedReasonTypeFromString;
virDomainPausedReasonTypeToString;
virDomainPciRombarModeTypeFromString;
virDomainPciRombarModeTypeToString;
virDomainPMStateTypeFromString;
virDomainPMStateTypeToString;
virDomainRedirdevBusTypeFromString;
virDomainRedirdevBusTypeToString;
virDomainRemoveInactive;
virDomainRunningReasonTypeFromString;
virDomainRunningReasonTypeToString;
virDomainSaveConfig;
virDomainSaveStatus;
virDomainSaveXML;
virDomainSeclabelTypeFromString;
virDomainSeclabelTypeToString;
virDomainShutdownReasonTypeFromString;
virDomainShutdownReasonTypeToString;
virDomainShutoffReasonTypeFromString;
virDomainShutoffReasonTypeToString;
virDomainSmartcardDefForeach;
virDomainSmartcardDefFree;
virDomainSmartcardTypeFromString;
virDomainSmartcardTypeToString;
virDomainSmbiosModeTypeFromString;
virDomainSmbiosModeTypeToString;
virDomainSoundDefFree;
virDomainSoundModelTypeFromString;
virDomainSoundModelTypeToString;
virDomainStartupPolicyTypeFromString;
virDomainStartupPolicyTypeToString;
virDomainStateReasonFromString;
virDomainStateReasonToString;
virDomainStateTypeFromString;
virDomainStateTypeToString;
virDomainTaintTypeFromString;
virDomainTaintTypeToString;
virDomainTimerModeTypeFromString;
virDomainTimerModeTypeToString;
virDomainTimerNameTypeFromString;
virDomainTimerNameTypeToString;
virDomainTimerTickpolicyTypeFromString;
virDomainTimerTickpolicyTypeToString;
virDomainTimerTrackTypeFromString;
virDomainTimerTrackTypeToString;
virDomainVcpuPinAdd;
2012-09-14 07:46:58 +00:00
virDomainVcpuPinDefArrayFree;
virDomainVcpuPinDefCopy;
virDomainVcpuPinDefFree;
virDomainVcpuPinDel;
virDomainVcpuPinFindByVcpu;
virDomainVcpuPinIsDuplicate;
virDomainVideoDefFree;
virDomainVideoDefaultRAM;
virDomainVideoDefaultType;
virDomainVideoTypeFromString;
virDomainVideoTypeToString;
virDomainVirtTypeToString;
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;
virDomainWatchdogActionTypeFromString;
virDomainWatchdogActionTypeToString;
virDomainWatchdogModelTypeFromString;
virDomainWatchdogModelTypeToString;
# domain_event.h
virDomainEventBalloonChangeNewFromDom;
virDomainEventBalloonChangeNewFromObj;
virDomainEventBlockJobNewFromObj;
virDomainEventBlockJobNewFromDom;
virDomainEventControlErrorNewFromDom;
virDomainEventControlErrorNewFromObj;
virDomainEventDiskChangeNewFromDom;
virDomainEventDiskChangeNewFromObj;
virDomainEventFree;
virDomainEventGraphicsNewFromDom;
virDomainEventGraphicsNewFromObj;
virDomainEventIOErrorNewFromDom;
virDomainEventIOErrorNewFromObj;
virDomainEventIOErrorReasonNewFromDom;
virDomainEventIOErrorReasonNewFromObj;
virDomainEventNew;
virDomainEventNewFromDef;
virDomainEventNewFromDom;
virDomainEventNewFromObj;
virDomainEventPMSuspendNewFromDom;
virDomainEventPMSuspendNewFromObj;
virDomainEventPMWakeupNewFromDom;
virDomainEventPMWakeupNewFromObj;
virDomainEventRTCChangeNewFromDom;
virDomainEventRTCChangeNewFromObj;
virDomainEventRebootNew;
virDomainEventRebootNewFromDom;
virDomainEventRebootNewFromObj;
virDomainEventStateDeregister;
virDomainEventStateDeregisterID;
virDomainEventStateEventID;
virDomainEventStateRegister;
virDomainEventStateRegisterID;
virDomainEventStateFree;
virDomainEventStateNew;
virDomainEventStateQueue;
virDomainEventPMSuspendDiskNewFromDom;
virDomainEventPMSuspendDiskNewFromObj;
virDomainEventTrayChangeNewFromDom;
virDomainEventTrayChangeNewFromObj;
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
virEventPollAddHandle;
virEventPollAddTimeout;
virEventPollFromNativeEvents;
virEventPollInit;
virEventPollRemoveHandle;
virEventPollRemoveTimeout;
virEventPollRunOnce;
virEventPollToNativeEvents;
virEventPollUpdateHandle;
virEventPollUpdateTimeout;
# fdstream.h
virFDStreamOpen;
virFDStreamConnectUNIX;
virFDStreamOpenFile;
virFDStreamCreateFile;
# hash.h
virHashAddEntry;
virHashCreate;
virHashEqual;
virHashForEach;
virHashFree;
virHashGetItems;
virHashLookup;
virHashRemoveAll;
virHashRemoveEntry;
virHashRemoveSet;
virHashSearch;
virHashSize;
virHashSteal;
virHashTableSize;
virHashUpdateEntry;
# hooks.h
virHookCall;
virHookInitialize;
virHookPresent;
# 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;
virJSONValueObjectGetKey;
virJSONValueObjectGetNumberDouble;
virJSONValueObjectGetNumberInt;
virJSONValueObjectGetNumberLong;
virJSONValueObjectGetNumberUint;
virJSONValueObjectGetNumberUlong;
virJSONValueObjectGetString;
virJSONValueObjectGetValue;
virJSONValueObjectHasKey;
virJSONValueObjectIsNull;
virJSONValueObjectKeysNumber;
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;
virLockManagerSetPluginDir;
# logging.h
virLogDefineFilter;
virLogDefineOutput;
virLogEmergencyDumpAll;
virLogGetDefaultPriority;
virLogGetFilters;
virLogGetNbFilters;
virLogGetNbOutputs;
virLogGetOutputs;
virLogLock;
virLogMessage;
virLogParseDefaultPriority;
virLogParseFilters;
virLogParseOutputs;
virLogReset;
virLogSetBufferSize;
virLogSetDefaultPriority;
virLogSetFromEnv;
virLogUnlock;
# memory.h
virAlloc;
virAllocN;
virAllocVar;
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT I noticed when writing the backend functions for virNetworkUpdate that I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and messed up the args to memmove at least once), and had seen the same sequence in a lot of other places, so I decided to write a few utility functions/macros - see the .h file for full documentation. The intent is to reduce the number of lines of code, but more importantly to eliminate the need to check the element size and element count arithmetic every time we need to do this (I *always* make at least one mistake.) VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an array of objects. The size of each object is determined automatically by the macro using sizeof(*array). The new element's contents are copied into the inserted space, then the original copy of contents are 0'ed out (if everything else was successful). Compile-time assignment and size compatibility between the array and the new element is guaranteed (see explanation below [*]) VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that the original contents of newelem are not cleared to 0 (i.e. a copy is made). VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT that "inserts" one past the current last element. VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that the original contents of newelem are not cleared to 0 (i.e. a copy is made). VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an array of objects. It's assumed that the element being deleted is already saved elsewhere (or cleared, if that's what is appropriate). All five of these macros have an _INPLACE variant, which skips the memory re-allocation of the array, assuming that the caller has already done it (when inserting) or will do it later (when deleting). Note that VIR_DELETE_ELEMENT* can return a failure, but only if an invalid index is given (index + amount to delete is > current array size), so in most cases you can safely ignore the return (that's why the helper function virDeleteElementsN isn't declared with ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens, since it is surely a coding error. [*] One initial problem with the INSERT and APPEND macros was that, due to both the array pointer and newelem pointer being cast to void* when passing to virInsertElementsN(), any chance of type-checking was lost. If we were going to move in newelem with a memmove anyway, we would be no worse off for this. However, most current open-coded insert/append operations use direct struct assignment to move the new element into place (or just populate the new element directly) - thus use of the new macros would open a possibility for new usage errors that didn't exist before (e.g. accidentally sending &newelemptr rather than newelemptr - I actually did this quite a lot in my test conversions of existing code). But thanks to Eric Blake's clever thinking, I was able to modify the INSERT and APPEND macros so that they *do* check for both assignment and size compatibility of *ptr (an element in the array) and newelem (the element being copied into the new position of the array). This is done via clever use of the C89-guaranteed fact that the sizeof() operator must have *no* side effects (so an assignment inside sizeof() is checked for validity, but not actually evaluated), and the fact that virInsertElementsN has a "# of new elements" argument that we want to always be 1.
2012-10-08 17:33:35 +00:00
virDeleteElementsN;
virExpandN;
virFree;
util: add VIR_(APPEND|INSERT|DELETE)_ELEMENT I noticed when writing the backend functions for virNetworkUpdate that I was repeating the same sequence of memmove, VIR_REALLOC, nXXX-- (and messed up the args to memmove at least once), and had seen the same sequence in a lot of other places, so I decided to write a few utility functions/macros - see the .h file for full documentation. The intent is to reduce the number of lines of code, but more importantly to eliminate the need to check the element size and element count arithmetic every time we need to do this (I *always* make at least one mistake.) VIR_INSERT_ELEMENT: insert one element at an arbitrary index within an array of objects. The size of each object is determined automatically by the macro using sizeof(*array). The new element's contents are copied into the inserted space, then the original copy of contents are 0'ed out (if everything else was successful). Compile-time assignment and size compatibility between the array and the new element is guaranteed (see explanation below [*]) VIR_INSERT_ELEMENT_COPY: identical to VIR_INSERT_ELEMENT, except that the original contents of newelem are not cleared to 0 (i.e. a copy is made). VIR_APPEND_ELEMENT: This is just a special case of VIR_INSERT_ELEMENT that "inserts" one past the current last element. VIR_APPEND_ELEMENT_COPY: identical to VIR_APPEND_ELEMENT, except that the original contents of newelem are not cleared to 0 (i.e. a copy is made). VIR_DELETE_ELEMENT: delete one element at an arbitrary index within an array of objects. It's assumed that the element being deleted is already saved elsewhere (or cleared, if that's what is appropriate). All five of these macros have an _INPLACE variant, which skips the memory re-allocation of the array, assuming that the caller has already done it (when inserting) or will do it later (when deleting). Note that VIR_DELETE_ELEMENT* can return a failure, but only if an invalid index is given (index + amount to delete is > current array size), so in most cases you can safely ignore the return (that's why the helper function virDeleteElementsN isn't declared with ATTRIBUTE_RETURN_CHECK). A warning is logged if this ever happens, since it is surely a coding error. [*] One initial problem with the INSERT and APPEND macros was that, due to both the array pointer and newelem pointer being cast to void* when passing to virInsertElementsN(), any chance of type-checking was lost. If we were going to move in newelem with a memmove anyway, we would be no worse off for this. However, most current open-coded insert/append operations use direct struct assignment to move the new element into place (or just populate the new element directly) - thus use of the new macros would open a possibility for new usage errors that didn't exist before (e.g. accidentally sending &newelemptr rather than newelemptr - I actually did this quite a lot in my test conversions of existing code). But thanks to Eric Blake's clever thinking, I was able to modify the INSERT and APPEND macros so that they *do* check for both assignment and size compatibility of *ptr (an element in the array) and newelem (the element being copied into the new position of the array). This is done via clever use of the C89-guaranteed fact that the sizeof() operator must have *no* side effects (so an assignment inside sizeof() is checked for validity, but not actually evaluated), and the fact that virInsertElementsN has a "# of new elements" argument that we want to always be 1.
2012-10-08 17:33:35 +00:00
virInsertElementsN;
virReallocN;
virResizeN;
virShrinkN;
# netdev_bandwidth_conf.h
virNetDevBandwidthFormat;
virNetDevBandwidthParse;
conf: add <vlan> element to network and domain interface elements The following config elements now support a <vlan> subelements: within a domain: <interface>, and the <actual> subelement of <interface> within a network: the toplevel, as well as any <portgroup> Each vlan element must have one or more <tag id='n'/> subelements. If there is more than one tag, it is assumed that vlan trunking is being requested. If trunking is required with only a single tag, the attribute "trunk='yes'" should be added to the toplevel <vlan> element. Some examples: <interface type='hostdev'/> <vlan> <tag id='42'/> </vlan> <mac address='52:54:00:12:34:56'/> ... </interface> <network> <name>vlan-net</name> <vlan trunk='yes'> <tag id='30'/> </vlan> <virtualport type='openvswitch'/> </network> <interface type='network'/> <source network='vlan-net'/> ... </interface> <network> <name>trunk-vlan</name> <vlan> <tag id='42'/> <tag id='43'/> </vlan> ... </network> <network> <name>multi</name> ... <portgroup name='production'/> <vlan> <tag id='42'/> </vlan> </portgroup> <portgroup name='test'/> <vlan> <tag id='666'/> </vlan> </portgroup> </network> <interface type='network'/> <source network='multi' portgroup='test'/> ... </interface> IMPORTANT NOTE: As of this patch there is no backend support for the vlan element for *any* network device type. When support is added in later patches, it will only be for those select network types that support setting up a vlan on the host side, without the guest's involvement. (For example, it will be possible to configure a vlan for a guest connected to an openvswitch bridge, but it won't be possible to do that for one that is connected to a standard Linux host bridge.)
2012-08-12 07:51:30 +00:00
#netdev_vlan_conf.h
virNetDevVlanFormat;
virNetDevVlanParse;
# netdev_vportprofile_conf.h
virNetDevVPortProfileFormat;
virNetDevVPortProfileParse;
virNetDevVPortTypeFromString;
virNetDevVPortTypeToString;
# network_conf.h
virNetworkAssignDef;
virNetworkConfigFile;
virNetworkConfigChangeSetup;
virNetworkDefCopy;
virNetworkDefFormat;
virNetworkDefFree;
virNetworkDefGetIpByIndex;
virNetworkDefParseFile;
virNetworkDefParseNode;
virNetworkDefParseString;
virNetworkDeleteConfig;
virNetworkFindByName;
virNetworkFindByUUID;
virNetworkForwardTypeToString;
virNetworkIpDefNetmask;
virNetworkIpDefPrefix;
virNetworkList;
virNetworkLoadAllConfigs;
virNetworkObjAssignDef;
virNetworkObjFree;
virNetworkObjGetPersistentDef;
virNetworkObjIsDuplicate;
virNetworkObjListFree;
virNetworkObjLock;
virNetworkObjReplacePersistentDef;
virNetworkObjSetDefTransient;
virNetworkObjUnlock;
network: free/null newDef if network fails to start https://bugzilla.redhat.com/show_bug.cgi?id=866364 pointed out a crash due to virNetworkObjAssignDef free'ing network->newDef without NULLing it afterward. A fix for this is in upstream commit b7e9202401ebaa039b8f05acdefda8c24081537a. While the NULLing of newDef was a legitimate fix, newDef should have already been empty (NULL) anyway (as indicated in the comment that was deleted by that commit). The reason that newDef had a non-NULL value (i.e. the root cause) was that networkStartNetwork() had failed after populating network->newDef, but then neglected to free/NULL newDef in the cleanup. (A bit of background here: network->newDef should contain the persistent config of a network when a network is active (and of course only when it is persisten), and NULL at all other times. There is also a network->def which should contain the persistent definition of the network when it is inactive, and the current live state at all other times. The idea is that you can make changes to network->newDef which will take effect the next time the network is restarted, but won't mess with the current state of the network (virDomainObj has a similar pair of virDomainDefs that behave in the same fashion). Personally I think there should be a network->live and network->config, and the location of the persistent config should *always* be in network->config, but that's for a later cleanup). Since I love things to be symmetric, I created a new function called virNetworkObjUnsetDefTransient(), which reverses the effects of virNetworkObjSetDefTransient(). I don't really like the name of the new function, but then I also didn't really like the name of the old one either (it's just named that way to match a similar function in the domain conf code).
2012-10-19 16:13:49 +00:00
virNetworkObjUnsetDefTransient;
virNetworkObjUpdate;
virNetworkRemoveInactive;
virNetworkSaveConfig;
virNetworkSaveStatus;
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
virNodeDevCapTypeFromString;
virNodeDevCapTypeToString;
virNodeDevCapsDefFree;
virNodeDeviceAssignDef;
virNodeDeviceDefFormat;
virNodeDeviceDefFree;
virNodeDeviceDefParseFile;
virNodeDeviceDefParseNode;
virNodeDeviceDefParseString;
virNodeDeviceFindByName;
virNodeDeviceFindBySysfsPath;
virNodeDeviceGetParentHost;
virNodeDeviceGetWWNs;
virNodeDeviceHasCap;
virNodeDeviceList;
virNodeDeviceObjListFree;
virNodeDeviceObjLock;
virNodeDeviceObjRemove;
virNodeDeviceObjUnlock;
# nodeinfo.h
nodeCapsInitNUMA;
nodeGetCPUBitmap;
nodeGetCPUCount;
nodeGetCPUMap;
nodeGetCPUStats;
nodeGetCellsFreeMemory;
nodeGetFreeMemory;
nodeGetInfo;
nodeGetMemoryParameters;
nodeGetMemoryStats;
nodeSetMemoryParameters;
# nwfilter_conf.h
virNWFilterCallbackDriversLock;
virNWFilterCallbackDriversUnlock;
virNWFilterChainSuffixTypeToString;
virNWFilterConfLayerInit;
virNWFilterConfLayerShutdown;
virNWFilterDefFormat;
virNWFilterDefFree;
virNWFilterDefParseString;
virNWFilterInstFiltersOnAllVMs;
virNWFilterJumpTargetTypeToString;
virNWFilterLoadAllConfigs;
virNWFilterLockFilterUpdates;
virNWFilterObjAssignDef;
virNWFilterObjDeleteDef;
virNWFilterObjFindByName;
virNWFilterObjFindByUUID;
virNWFilterObjListFree;
virNWFilterObjLock;
virNWFilterObjRemove;
virNWFilterObjSaveDef;
virNWFilterObjUnlock;
virNWFilterPrintStateMatchFlags;
virNWFilterPrintTCPFlags;
virNWFilterRegisterCallbackDriver;
virNWFilterRuleActionTypeToString;
virNWFilterRuleDirectionTypeToString;
virNWFilterRuleProtocolTypeToString;
virNWFilterTestUnassignDef;
nwfilter: fix crash during filter define when lxc driver failed startup The meat of this patch is just moving the calls to virNWFilterRegisterCallbackDriver from each hypervisor's "register" function into its "initialize" function. The rest is just code movement to allow that, and a new virNWFilterUnRegisterCallbackDriver function to undo what the register function does. The long explanation: There is an array in nwfilter called callbackDrvArray that has pointers to a table of functions for each hypervisor driver that are called by nwfilter. One of those function pointers is to a function that will lock the hypervisor driver. Entries are added to the table by calling each driver's "register" function, which happens quite early in libvirtd's startup. Sometime later, each driver's "initialize" function is called. This function allocates a driver object and stores a pointer to it in a static variable that was previously initialized to NULL. (and here's the important part...) If the "initialize" function fails, the driver object is freed, and that pointer set back to NULL (but the entry in nwfilter's callbackDrvArray is still there). When the "lock the driver" function mentioned above is called, it assumes that the driver was successfully loaded, so it blindly tries to call virMutexLock on "driver->lock". BUT, if the initialize never happened, or if it failed, "driver" is NULL. And it just happens that "lock" is always the first field in driver so it is also NULL. Boom. To fix this, the call to virNWFilterRegisterCallbackDriver for each driver shouldn't be called until the end of its (*already guaranteed successful*) "initialize" function, not during its "register" function (which is currently the case). This implies that there should also be a virNWFilterUnregisterCallbackDriver() function that is called in a driver's "shutdown" function (although in practice, that function is currently never called).
2012-08-09 06:18:23 +00:00
virNWFilterUnRegisterCallbackDriver;
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_ipaddrmap
virNWFilterIPAddrMapAddIPAddr;
virNWFilterIPAddrMapDelIPAddr;
virNWFilterIPAddrMapGetIPAddr;
virNWFilterIPAddrMapInit;
virNWFilterIPAddrMapShutdown;
# nwfilter_params.h
virNWFilterHashTableCreate;
virNWFilterHashTableEqual;
virNWFilterHashTableFree;
virNWFilterHashTablePut;
virNWFilterHashTablePutAll;
virNWFilterHashTableRemoveEntry;
virNWFilterVarAccessGetVarName;
virNWFilterVarAccessIsAvailable;
virNWFilterVarAccessPrint;
virNWFilterVarCombIterCreate;
virNWFilterVarCombIterFree;
virNWFilterVarCombIterGetVarValue;
virNWFilterVarCombIterNext;
virNWFilterVarValueAddValue;
virNWFilterVarValueCopy;
virNWFilterVarValueCreateSimple;
virNWFilterVarValueCreateSimpleCopyValue;
virNWFilterVarValueDelValue;
virNWFilterVarValueEqual;
virNWFilterVarValueFree;
virNWFilterVarValueGetCardinality;
virNWFilterVarValueGetNthValue;
virNWFilterVarValueGetSimple;
# pci.h
pciConfigAddressToSysfsFile;
pciDettachDevice;
pciDeviceFileIterate;
pciDeviceGetManaged;
qemu: Do not reattach PCI device used by other domain when shutdown When failing on starting a domain, it tries to reattach all the PCI devices defined in the domain conf, regardless of whether the devices are still used by other domain. This will cause the devices to be deleted from the list qemu_driver->activePciHostdevs, thus the devices will be thought as usable even if it's not true. And following commands nodedev-{reattach,reset} will be successful. How to reproduce: 1) Define two domains with same PCI device defined in the confs. 2) # virsh start domain1 3) # virsh start domain2 4) # virsh nodedev-reattach $pci_device You will see the device will be reattached to host successfully. As pciDeviceReattach just check if the device is still used by other domain via checking if the device is in list driver->activePciHostdevs, however, the device is deleted from the list by step 2). This patch is to prohibit the bug by: 1) Prohibit a domain starting or device attachment right at preparation period (qemuPrepareHostdevPCIDevices) if the device is in list driver->activePciHostdevs, which means it's used by other domain. 2) Introduces a new field for struct _pciDevice, (const char *used_by), it will be set as the domain name at preparation period, (qemuPrepareHostdevPCIDevices). Thus we can prohibit deleting the device from driver->activePciHostdevs if it's still used by other domain when stopping the domain process. * src/pci.h (define two internal functions, pciDeviceSetUsedBy and pciDevceGetUsedBy) * src/pci.c (new field "const char *used_by" for struct _pciDevice, implementations for the two new functions) * src/libvirt_private.syms (Add the two new internal functions) * src/qemu_hostdev.h (Modify the definition of functions qemuPrepareHostdevPCIDevices, and qemuDomainReAttachHostdevDevices) * src/qemu_hostdev.c (Prohibit preparation and don't delete the device from activePciHostdevs list if it's still used by other domain) * src/qemu_hotplug.c (Update function usage, as the definitions are changed) Signed-off-by: Eric Blake <eblake@redhat.com>
2011-10-13 04:05:04 +00:00
pciDeviceGetName;
pciDeviceGetRemoveSlot;
pciDeviceGetReprobe;
pciDeviceGetUnbindFromStub;
qemu: Do not reattach PCI device used by other domain when shutdown When failing on starting a domain, it tries to reattach all the PCI devices defined in the domain conf, regardless of whether the devices are still used by other domain. This will cause the devices to be deleted from the list qemu_driver->activePciHostdevs, thus the devices will be thought as usable even if it's not true. And following commands nodedev-{reattach,reset} will be successful. How to reproduce: 1) Define two domains with same PCI device defined in the confs. 2) # virsh start domain1 3) # virsh start domain2 4) # virsh nodedev-reattach $pci_device You will see the device will be reattached to host successfully. As pciDeviceReattach just check if the device is still used by other domain via checking if the device is in list driver->activePciHostdevs, however, the device is deleted from the list by step 2). This patch is to prohibit the bug by: 1) Prohibit a domain starting or device attachment right at preparation period (qemuPrepareHostdevPCIDevices) if the device is in list driver->activePciHostdevs, which means it's used by other domain. 2) Introduces a new field for struct _pciDevice, (const char *used_by), it will be set as the domain name at preparation period, (qemuPrepareHostdevPCIDevices). Thus we can prohibit deleting the device from driver->activePciHostdevs if it's still used by other domain when stopping the domain process. * src/pci.h (define two internal functions, pciDeviceSetUsedBy and pciDevceGetUsedBy) * src/pci.c (new field "const char *used_by" for struct _pciDevice, implementations for the two new functions) * src/libvirt_private.syms (Add the two new internal functions) * src/qemu_hostdev.h (Modify the definition of functions qemuPrepareHostdevPCIDevices, and qemuDomainReAttachHostdevDevices) * src/qemu_hostdev.c (Prohibit preparation and don't delete the device from activePciHostdevs list if it's still used by other domain) * src/qemu_hotplug.c (Update function usage, as the definitions are changed) Signed-off-by: Eric Blake <eblake@redhat.com>
2011-10-13 04:05:04 +00:00
pciDeviceGetUsedBy;
pciDeviceGetVirtualFunctionInfo;
pciDeviceIsAssignable;
pciDeviceIsVirtualFunction;
pciDeviceListAdd;
pciDeviceListCount;
pciDeviceListDel;
pciDeviceListFind;
pciDeviceListFindIndex;
pciDeviceListFree;
pciDeviceListGet;
pciDeviceListNew;
pciDeviceListSteal;
pciDeviceListStealIndex;
pciDeviceNetName;
pciDeviceReAttachInit;
pciDeviceSetManaged;
pciDeviceSetRemoveSlot;
pciDeviceSetReprobe;
pciDeviceSetUnbindFromStub;
qemu: Do not reattach PCI device used by other domain when shutdown When failing on starting a domain, it tries to reattach all the PCI devices defined in the domain conf, regardless of whether the devices are still used by other domain. This will cause the devices to be deleted from the list qemu_driver->activePciHostdevs, thus the devices will be thought as usable even if it's not true. And following commands nodedev-{reattach,reset} will be successful. How to reproduce: 1) Define two domains with same PCI device defined in the confs. 2) # virsh start domain1 3) # virsh start domain2 4) # virsh nodedev-reattach $pci_device You will see the device will be reattached to host successfully. As pciDeviceReattach just check if the device is still used by other domain via checking if the device is in list driver->activePciHostdevs, however, the device is deleted from the list by step 2). This patch is to prohibit the bug by: 1) Prohibit a domain starting or device attachment right at preparation period (qemuPrepareHostdevPCIDevices) if the device is in list driver->activePciHostdevs, which means it's used by other domain. 2) Introduces a new field for struct _pciDevice, (const char *used_by), it will be set as the domain name at preparation period, (qemuPrepareHostdevPCIDevices). Thus we can prohibit deleting the device from driver->activePciHostdevs if it's still used by other domain when stopping the domain process. * src/pci.h (define two internal functions, pciDeviceSetUsedBy and pciDevceGetUsedBy) * src/pci.c (new field "const char *used_by" for struct _pciDevice, implementations for the two new functions) * src/libvirt_private.syms (Add the two new internal functions) * src/qemu_hostdev.h (Modify the definition of functions qemuPrepareHostdevPCIDevices, and qemuDomainReAttachHostdevDevices) * src/qemu_hostdev.c (Prohibit preparation and don't delete the device from activePciHostdevs list if it's still used by other domain) * src/qemu_hotplug.c (Update function usage, as the definitions are changed) Signed-off-by: Eric Blake <eblake@redhat.com>
2011-10-13 04:05:04 +00:00
pciDeviceSetUsedBy;
pciFreeDevice;
pciGetDevice;
pciGetPhysicalFunction;
pciGetVirtualFunctionIndex;
pciGetVirtualFunctions;
pciReAttachDevice;
pciResetDevice;
pciWaitForDeviceCleanup;
# processinfo.h
virProcessInfoGetAffinity;
virProcessInfoSetAffinity;
# secret_conf.h
virSecretDefFormat;
virSecretDefFree;
virSecretDefParseFile;
virSecretDefParseString;
virSecretUsageTypeTypeFromString;
virSecretUsageTypeTypeToString;
# security_driver.h
virSecurityDriverLookup;
# security_manager.h
virSecurityManagerClearSocketLabel;
virSecurityManagerFree;
virSecurityManagerGenLabel;
virSecurityManagerGetDOI;
virSecurityManagerGetModel;
virSecurityManagerGetNested;
virSecurityManagerGetProcessLabel;
virSecurityManagerNew;
virSecurityManagerNewStack;
virSecurityManagerNewDAC;
virSecurityManagerReleaseLabel;
virSecurityManagerReserveLabel;
virSecurityManagerRestoreImageLabel;
virSecurityManagerRestoreAllLabel;
virSecurityManagerRestoreHostdevLabel;
virSecurityManagerRestoreSavedStateLabel;
virSecurityManagerSetAllLabel;
virSecurityManagerSetDaemonSocketLabel;
virSecurityManagerSetImageFDLabel;
virSecurityManagerSetImageLabel;
virSecurityManagerSetHostdevLabel;
virSecurityManagerSetProcessLabel;
virSecurityManagerSetSavedStateLabel;
virSecurityManagerSetSocketLabel;
virSecurityManagerSetTapFDLabel;
virSecurityManagerStackAddNested;
virSecurityManagerVerify;
virSecurityManagerGetMountOptions;
# 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;
# snapshot_conf.h
virDomainListSnapshots;
virDomainSnapshotAlignDisks;
virDomainSnapshotAssignDef;
virDomainSnapshotDefFormat;
virDomainSnapshotDefFree;
virDomainSnapshotDefParseString;
virDomainSnapshotDropParent;
virDomainSnapshotFindByName;
virDomainSnapshotForEach;
virDomainSnapshotForEachChild;
virDomainSnapshotForEachDescendant;
virDomainSnapshotIsExternal;
virDomainSnapshotLocationTypeFromString;
virDomainSnapshotLocationTypeToString;
virDomainSnapshotObjListGetNames;
virDomainSnapshotObjListNum;
virDomainSnapshotObjListRemove;
virDomainSnapshotStateTypeFromString;
virDomainSnapshotStateTypeToString;
virDomainSnapshotUpdateRelations;
# storage_conf.h
virStoragePartedFsTypeTypeToString;
virStoragePoolDefFormat;
virStoragePoolDefFree;
virStoragePoolDefParseFile;
virStoragePoolDefParseNode;
virStoragePoolDefParseSourceString;
virStoragePoolDefParseString;
virStoragePoolFormatDiskTypeToString;
virStoragePoolFormatFileSystemNetTypeToString;
virStoragePoolFormatFileSystemTypeToString;
virStoragePoolList;
virStoragePoolLoadAllConfigs;
virStoragePoolObjAssignDef;
virStoragePoolObjClearVols;
virStoragePoolObjDeleteDef;
virStoragePoolObjFindByName;
virStoragePoolObjFindByUUID;
virStoragePoolObjIsDuplicate;
virStoragePoolObjListFree;
virStoragePoolObjLock;
virStoragePoolObjRemove;
virStoragePoolObjSaveDef;
virStoragePoolObjUnlock;
virStoragePoolSourceClear;
virStoragePoolSourceFindDuplicate;
virStoragePoolSourceFindDuplicateDevices;
virStoragePoolSourceFree;
virStoragePoolSourceListFormat;
virStoragePoolSourceListNewSource;
virStoragePoolTypeFromString;
virStorageVolDefFindByKey;
virStorageVolDefFindByName;
virStorageVolDefFindByPath;
virStorageVolDefFormat;
virStorageVolDefFree;
virStorageVolDefParseFile;
virStorageVolDefParseNode;
virStorageVolDefParseString;
# storage_encryption_conf.h
virStorageEncryptionFormat;
virStorageEncryptionFree;
virStorageEncryptionParseNode;
virStorageGenerateQcowPassphrase;
# storage_file.h
virStorageFileChainLookup;
virStorageFileFormatTypeFromString;
virStorageFileFormatTypeToString;
virStorageFileFreeMetadata;
virStorageFileGetMetadata;
virStorageFileGetMetadataFromFD;
2012-02-21 21:58:50 +00:00
virStorageFileIsClusterFS;
virStorageFileIsSharedFS;
virStorageFileIsSharedFSType;
virStorageFileProbeFormat;
virStorageFileProbeFormatFromFD;
virStorageFileResize;
# sysinfo.h
virSysinfoDefFree;
virSysinfoFormat;
virSysinfoRead;
# threadpool.h
virThreadPoolFree;
virThreadPoolNew;
virThreadPoolSendJob;
virThreadPoolGetMinWorkers;
virThreadPoolGetMaxWorkers;
virThreadPoolGetPriorityWorkers;
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;
virThreadInitialize;
virThreadIsSelf;
virThreadJoin;
virThreadSelf;
virThreadSelfID;
2009-01-15 19:56:05 +00:00
# usb.h
usbDeviceFileIterate;
usbDeviceGetBus;
usbDeviceGetDevno;
usbDeviceGetName;
usbDeviceGetUsedBy;
usbDeviceListAdd;
usbDeviceListCount;
usbDeviceListDel;
usbDeviceListFind;
usbDeviceListFree;
usbDeviceListGet;
usbDeviceListNew;
usbDeviceListSteal;
usbDeviceSetUsedBy;
usbFindDevice;
usbFindDeviceByBus;
usbFindDeviceByVendor;
usbFreeDevice;
usbGetDevice;
2009-01-15 19:56:05 +00:00
# util.h
saferead;
safewrite;
safezero;
virArgvToString;
virAsprintf;
virBuildPathInternal;
virDirCreate;
virDoubleToStr;
virEnumFromString;
virEnumToString;
virFileAbsPath;
virFileAccessibleAs;
virFileBuildPath;
virFileExists;
virFileFindMountPoint;
virFileHasSuffix;
virFileIsAbsPath;
virFileIsExecutable;
virFileIsLink;
virFileIsDir;
virFileLinkPointsTo;
virFileLock;
virFileMakePath;
virFileMakePathWithMode;
virFileMatchesNameSuffix;
virFileOpenAs;
virFileOpenTty;
virFileReadAll;
virFileReadLimFD;
virFileResolveAllLinks;
virFileResolveLink;
virFileSanitizePath;
virFileSkipRoot;
virFileStripSuffix;
virFileUnlock;
virFileWaitForDevices;
virFileWriteStr;
virFindFileInPath;
virFormatIntDecimal;
virGetGroupID;
virGetGroupName;
virGetHostname;
virGetUserDirectory;
virGetUserConfigDirectory;
virGetUserCacheDirectory;
virGetUserRuntimeDirectory;
virGetUserID;
virGetUserName;
virHexToBin;
virIndexToDiskName;
virIsDevMapperDevice;
virParseNumber;
virParseVersionString;
virPipeReadUntilEOF;
virScaleInteger;
virSetBlocking;
virSetCloseExec;
virSetInherit;
virSetNonBlock;
virSetUIDGID;
virSkipSpaces;
virSkipSpacesAndBackslash;
virSkipSpacesBackwards;
virStrIsPrint;
virStrToDouble;
virStrToLong_i;
virStrToLong_l;
virStrToLong_ll;
virStrToLong_ui;
virStrToLong_ul;
virStrToLong_ull;
virStrcpy;
virStrncpy;
virTrimSpaces;
virValidateWWN;
virVasprintf;
# uuid.h
virGetHostUUID;
virSetHostUUIDStr;
virUUIDFormat;
virUUIDGenerate;
virUUIDIsValid;
virUUIDParse;
# virauth.h
virAuthGetConfigFilePath;
virAuthGetPassword;
virAuthGetUsername;
# virauthconfig.h
virAuthConfigFree;
virAuthConfigLookup;
virAuthConfigNew;
virAuthConfigNewData;
# viraudit.h
virAuditClose;
virAuditEncode;
virAuditLog;
virAuditOpen;
virAuditSend;
# virconsole.h
virConsoleAlloc;
virConsoleFree;
virConsoleOpen;
# virdbus.h
virDBusGetSessionBus;
virDBusGetSystemBus;
# virfile.h
virFileLoopDeviceAssociate;
virFileClose;
virFileDirectFdFlag;
virFileWrapperFdCatchError;
virFileWrapperFdClose;
virFileWrapperFdFree;
virFileWrapperFdNew;
virFileFclose;
virFileFdopen;
virFileRewrite;
virFileTouch;
virFileUpdatePerm;
# virinitctl.h
virInitctlSetRunLevel;
# virkeycode.h
virKeycodeSetTypeFromString;
virKeycodeSetTypeToString;
virKeycodeValueFromString;
virKeycodeValueTranslate;
# virkeyfile.h
virKeyFileNew;
virKeyFileLoadFile;
virKeyFileLoadData;
virKeyFileFree;
virKeyFileHasValue;
virKeyFileHasGroup;
virKeyFileGetValueString;
Introduce an internal API for handling file based lockspaces The previously introduced virFile{Lock,Unlock} APIs provide a way to acquire/release fcntl() locks on individual files. For unknown reason though, the POSIX spec says that fcntl() locks are released when *any* file handle referring to the same path is closed. In the following sequence threadA: fd1 = open("foo") threadB: fd2 = open("foo") threadA: virFileLock(fd1) threadB: virFileLock(fd2) threadB: close(fd2) you'd expect threadA to come out holding a lock on 'foo', and indeed it does hold a lock for a very short time. Unfortunately when threadB does close(fd2) this releases the lock associated with fd1. For the current libvirt use case for virFileLock - pidfiles - this doesn't matter since the lock is acquired at startup while single threaded an never released until exit. To provide a more generally useful API though, it is necessary to introduce a slightly higher level abstraction, which is to be referred to as a "lockspace". This is to be provided by a virLockSpacePtr object in src/util/virlockspace.{c,h}. The core idea is that the lockspace keeps track of what files are already open+locked. This means that when a 2nd thread comes along and tries to acquire a lock, it doesn't end up opening and closing a new FD. The lockspace just checks the current list of held locks and immediately returns VIR_ERR_RESOURCE_BUSY. NB, the API as it stands is designed on the basis that the files being locked are not being otherwise opened and used by the application code. One approach to using this API is to acquire locks based on a hash of the filepath. eg to lock /var/lib/libvirt/images/foo.img the application might do virLockSpacePtr lockspace = virLockSpaceNew("/var/lib/libvirt/imagelocks"); lockname = md5sum("/var/lib/libvirt/images/foo.img"); virLockSpaceAcquireLock(lockspace, lockname); NB, in this example, the caller should ensure that the path is canonicalized before calculating the checksum. It is also possible to do locks directly on resources by using a NULL lockspace directory and then using the file path as the lock name eg virLockSpacePtr lockspace = virLockSpaceNew(NULL); virLockSpaceAcquireLock(lockspace, "/var/lib/libvirt/images/foo.img"); This is only safe to do though if no other part of the process will be opening the files. This will be the case when this code is used inside the soon-to-be-reposted virlockd daemon Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-02 16:02:40 +00:00
# virlockspace.h
virLockSpaceAcquireResource;
virLockSpaceCreateResource;
virLockSpaceDeleteResource;
virLockSpaceFree;
virLockSpaceGetDirectory;
virLockSpaceNew;
virLockSpaceNewPostExecRestart;
virLockSpacePreExecRestart;
Introduce an internal API for handling file based lockspaces The previously introduced virFile{Lock,Unlock} APIs provide a way to acquire/release fcntl() locks on individual files. For unknown reason though, the POSIX spec says that fcntl() locks are released when *any* file handle referring to the same path is closed. In the following sequence threadA: fd1 = open("foo") threadB: fd2 = open("foo") threadA: virFileLock(fd1) threadB: virFileLock(fd2) threadB: close(fd2) you'd expect threadA to come out holding a lock on 'foo', and indeed it does hold a lock for a very short time. Unfortunately when threadB does close(fd2) this releases the lock associated with fd1. For the current libvirt use case for virFileLock - pidfiles - this doesn't matter since the lock is acquired at startup while single threaded an never released until exit. To provide a more generally useful API though, it is necessary to introduce a slightly higher level abstraction, which is to be referred to as a "lockspace". This is to be provided by a virLockSpacePtr object in src/util/virlockspace.{c,h}. The core idea is that the lockspace keeps track of what files are already open+locked. This means that when a 2nd thread comes along and tries to acquire a lock, it doesn't end up opening and closing a new FD. The lockspace just checks the current list of held locks and immediately returns VIR_ERR_RESOURCE_BUSY. NB, the API as it stands is designed on the basis that the files being locked are not being otherwise opened and used by the application code. One approach to using this API is to acquire locks based on a hash of the filepath. eg to lock /var/lib/libvirt/images/foo.img the application might do virLockSpacePtr lockspace = virLockSpaceNew("/var/lib/libvirt/imagelocks"); lockname = md5sum("/var/lib/libvirt/images/foo.img"); virLockSpaceAcquireLock(lockspace, lockname); NB, in this example, the caller should ensure that the path is canonicalized before calculating the checksum. It is also possible to do locks directly on resources by using a NULL lockspace directory and then using the file path as the lock name eg virLockSpacePtr lockspace = virLockSpaceNew(NULL); virLockSpaceAcquireLock(lockspace, "/var/lib/libvirt/images/foo.img"); This is only safe to do though if no other part of the process will be opening the files. This will be the case when this code is used inside the soon-to-be-reposted virlockd daemon Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-02 16:02:40 +00:00
virLockSpaceReleaseResource;
virLockSpaceReleaseResourcesForOwner;
# virmacaddr.h
virMacAddrCmp;
virMacAddrCmpRaw;
virMacAddrCompare;
virMacAddrFormat;
virMacAddrGenerate;
virMacAddrGetRaw;
virMacAddrIsBroadcastRaw;
virMacAddrIsMulticast;
virMacAddrIsUnicast;
virMacAddrParse;
virMacAddrSet;
virMacAddrSetRaw;
# virnetclient.h
virNetClientAddProgram;
virNetClientAddStream;
virNetClientClose;
virNetClientDupFD;
virNetClientGetFD;
virNetClientGetTLSKeySize;
virNetClientHasPassFD;
virNetClientIsEncrypted;
virNetClientIsOpen;
virNetClientKeepAliveIsSupported;
virNetClientKeepAliveStart;
virNetClientKeepAliveStop;
virNetClientLocalAddrString;
virNetClientNewExternal;
virNetClientNewLibSSH2;
virNetClientNewSSH;
virNetClientNewTCP;
virNetClientNewUNIX;
virNetClientRegisterAsyncIO;
virNetClientRegisterKeepAlive;
virNetClientRemoteAddrString;
virNetClientRemoveStream;
virNetClientSendNoReply;
virNetClientSendNonBlock;
virNetClientSendWithReply;
virNetClientSendWithReplyStream;
virNetClientSetCloseCallback;
virNetClientSetTLSSession;
# virnetclientprogram.h
virNetClientProgramCall;
virNetClientProgramDispatch;
virNetClientProgramGetProgram;
virNetClientProgramGetVersion;
virNetClientProgramMatches;
virNetClientProgramNew;
# virnetclientstream.h
virNetClientStreamEOF;
virNetClientStreamEventAddCallback;
virNetClientStreamEventRemoveCallback;
virNetClientStreamEventUpdateCallback;
virNetClientStreamMatches;
virNetClientStreamNew;
virNetClientStreamQueuePacket;
virNetClientStreamRaiseError;
virNetClientStreamRecvPacket;
virNetClientStreamSendPacket;
virNetClientStreamSetError;
# virnetdev.h
virNetDevClearIPv4Address;
virNetDevExists;
virNetDevGetIPv4Address;
virNetDevGetIndex;
virNetDevGetMAC;
virNetDevGetMTU;
virNetDevGetPhysicalFunction;
virNetDevGetVLanID;
virNetDevGetVirtualFunctionIndex;
virNetDevGetVirtualFunctionInfo;
virNetDevGetVirtualFunctions;
virNetDevIsOnline;
virNetDevIsVirtualFunction;
virNetDevLinkDump;
virNetDevReplaceMacAddress;
virNetDevReplaceNetConfig;
virNetDevRestoreMacAddress;
virNetDevRestoreNetConfig;
virNetDevSetIPv4Address;
virNetDevSetMAC;
virNetDevSetMTU;
virNetDevSetMTUFromDevice;
virNetDevSetName;
virNetDevSetNamespace;
virNetDevSetOnline;
virNetDevValidateConfig;
# virnetdevbandwidth.h
virNetDevBandwidthClear;
virNetDevBandwidthCopy;
virNetDevBandwidthEqual;
virNetDevBandwidthFree;
virNetDevBandwidthSet;
# virnetdevbridge.h
virNetDevBridgeAddPort;
virNetDevBridgeCreate;
virNetDevBridgeDelete;
virNetDevBridgeGetSTP;
virNetDevBridgeGetSTPDelay;
virNetDevBridgeRemovePort;
virNetDevBridgeSetSTP;
virNetDevBridgeSetSTPDelay;
# virnetdevmacvlan.h
virNetDevMacVLanCreate;
virNetDevMacVLanDelete;
virNetDevMacVLanCreateWithVPortProfile;
virNetDevMacVLanDeleteWithVPortProfile;
virNetDevMacVLanRestartWithVPortProfile;
virNetDevMacVLanVPortProfileRegisterCallback;
# virnetdevopenvswitch.h
virNetDevOpenvswitchAddPort;
virNetDevOpenvswitchGetMigrateData;
virNetDevOpenvswitchRemovePort;
virNetDevOpenvswitchSetMigrateData;
# virnetdevtap.h
virNetDevTapCreate;
virNetDevTapCreateInBridgePort;
virNetDevTapDelete;
# virnetdevveth.h
virNetDevVethCreate;
virNetDevVethDelete;
# virnetdevvlan.h
virNetDevVlanClear;
virNetDevVlanCopy;
virNetDevVlanEqual;
virNetDevVlanFree;
# virnetdevvportprofile.h
virNetDevVPortProfileAssociate;
virNetDevVPortProfileCheckComplete;
virNetDevVPortProfileCheckNoExtras;
virNetDevVPortProfileDisassociate;
virNetDevVPortProfileEqual;
virNetDevVPortProfileMerge3;
virNetDevVPortProfileOpTypeFromString;
virNetDevVPortProfileOpTypeToString;
#virnetlink.h
virNetlinkCommand;
virNetlinkEventAddClient;
virNetlinkEventRemoveClient;
virNetlinkEventServiceIsRunning;
virNetlinkEventServiceLocalPid;
virNetlinkEventServiceStop;
virNetlinkEventServiceStopAll;
virNetlinkEventServiceStart;
virNetlinkShutdown;
virNetlinkStartup;
# virnetmessage.h
virNetMessageClear;
virNetMessageDecodeHeader;
virNetMessageDecodeNumFDs;
virNetMessageDecodeLength;
virNetMessageDecodePayload;
virNetMessageDupFD;
virNetMessageEncodeHeader;
virNetMessageEncodePayload;
virNetMessageEncodePayloadRaw;
virNetMessageEncodeNumFDs;
virNetMessageFree;
virNetMessageNew;
virNetMessageQueuePush;
virNetMessageQueueServe;
virNetMessageSaveError;
xdr_virNetMessageError;
# virnetserver.h
virNetServerAddProgram;
virNetServerAddService;
virNetServerAddShutdownInhibition;
virNetServerAddSignalHandler;
virNetServerAutoShutdown;
virNetServerClose;
virNetServerIsPrivileged;
virNetServerKeepAliveRequired;
virNetServerNew;
virNetServerNewPostExecRestart;
virNetServerPreExecRestart;
virNetServerQuit;
virNetServerRemoveShutdownInhibition;
virNetServerRun;
virNetServerSetTLSContext;
virNetServerUpdateServices;
# virnetserverclient.h
virNetServerClientAddFilter;
virNetServerClientClose;
virNetServerClientDelayedClose;
virNetServerClientGetAuth;
virNetServerClientGetFD;
virNetServerClientGetIdentity;
virNetServerClientGetPrivateData;
virNetServerClientGetReadonly;
virNetServerClientGetTLSKeySize;
virNetServerClientGetUNIXIdentity;
virNetServerClientHasTLSSession;
virNetServerClientImmediateClose;
virNetServerClientInit;
virNetServerClientInitKeepAlive;
virNetServerClientIsClosed;
virNetServerClientIsSecure;
virNetServerClientLocalAddrString;
virNetServerClientNeedAuth;
virNetServerClientNew;
virNetServerClientNewPostExecRestart;
virNetServerClientPreExecRestart;
virNetServerClientRemoteAddrString;
virNetServerClientRemoveFilter;
virNetServerClientSendMessage;
virNetServerClientSetCloseHook;
virNetServerClientSetDispatcher;
virNetServerClientSetIdentity;
virNetServerClientStartKeepAlive;
virNetServerClientWantClose;
# virnetservermdns.h
virNetServerMDNSAddEntry;
virNetServerMDNSAddGroup;
virNetServerMDNSEntryFree;
virNetServerMDNSFree;
virNetServerMDNSGroupFree;
virNetServerMDNSNew;
virNetServerMDNSRemoveEntry;
virNetServerMDNSRemoveGroup;
virNetServerMDNSStart;
virNetServerMDNSStop;
# virnetserverprogram.h
virNetServerProgramDispatch;
virNetServerProgramGetID;
virNetServerProgramGetPriority;
virNetServerProgramGetVersion;
virNetServerProgramMatches;
virNetServerProgramNew;
virNetServerProgramSendReplyError;
virNetServerProgramSendStreamData;
virNetServerProgramSendStreamError;
virNetServerProgramUnknownError;
# virnetserverservice.h
virNetServerServiceClose;
virNetServerServiceGetAuth;
virNetServerServiceGetMaxRequests;
virNetServerServiceGetPort;
virNetServerServiceGetTLSContext;
virNetServerServiceIsReadonly;
virNetServerServiceNewFD;
virNetServerServiceNewPostExecRestart;
virNetServerServiceNewTCP;
virNetServerServiceNewUNIX;
virNetServerServicePreExecRestart;
virNetServerServiceSetDispatcher;
virNetServerServiceToggle;
# virnetsocket.h
virNetSocketAccept;
virNetSocketAddIOCallback;
virNetSocketClose;
virNetSocketDupFD;
virNetSocketGetFD;
virNetSocketGetPort;
virNetSocketGetUNIXIdentity;
virNetSocketHasCachedData;
virNetSocketHasPassFD;
virNetSocketHasPendingData;
virNetSocketIsLocal;
virNetSocketListen;
virNetSocketLocalAddrString;
virNetSocketNewConnectCommand;
virNetSocketNewConnectExternal;
virNetSocketNewConnectLibSSH2;
virNetSocketNewConnectSSH;
virNetSocketNewConnectTCP;
virNetSocketNewConnectUNIX;
virNetSocketNewListenFD;
virNetSocketNewListenTCP;
virNetSocketNewListenUNIX;
virNetSocketNewPostExecRestart;
virNetSocketPreExecRestart;
virNetSocketRead;
virNetSocketRecvFD;
virNetSocketRemoteAddrString;
virNetSocketRemoveIOCallback;
virNetSocketSendFD;
virNetSocketSetBlocking;
virNetSocketSetTLSSession;
virNetSocketUpdateIOCallback;
virNetSocketWrite;
# virnettlscontext.h
virNetTLSContextCheckCertificate;
virNetTLSContextNewClient;
virNetTLSContextNewClientPath;
virNetTLSContextNewServer;
virNetTLSContextNewServerPath;
virNetTLSInit;
virNetTLSSessionGetHandshakeStatus;
virNetTLSSessionGetKeySize;
virNetTLSSessionHandshake;
virNetTLSSessionNew;
virNetTLSSessionRead;
virNetTLSSessionSetIOCallbacks;
virNetTLSSessionWrite;
# virnodesuspend.h
nodeSuspendForDuration;
virNodeSuspendGetTargetMask;
Add a generic reference counted virObject type This introduces a fairly basic reference counted virObject type and an associated virClass type, that use atomic operations for ref counting. In a global initializer (recommended to be invoked using the virOnceInit API), a virClass type must be allocated for each object type. This requires a class name, a "dispose" callback which will be invoked to free memory associated with the object's fields, and the size in bytes of the object struct. eg, virClassPtr connclass = virClassNew("virConnect", sizeof(virConnect), virConnectDispose); The struct for the object, must include 'virObject' as its first member eg struct _virConnect { virObject object; virURIPtr uri; }; The 'dispose' callback is only responsible for freeing fields in the object, not the object itself. eg a suitable impl for the above struct would be void virConnectDispose(void *obj) { virConnectPtr conn = obj; virURIFree(conn->uri); } There is no need to reset fields to 'NULL' or '0' in the dispose callback, since the entire object will be memset to 0, and the klass pointer & magic integer fields will be poisoned with 0xDEADBEEF before being free()d When creating an instance of an object, one needs simply pass the virClassPtr eg virConnectPtr conn = virObjectNew(connclass); if (!conn) return NULL; conn->uri = virURIParse("foo:///bar") Object references can be manipulated with virObjectRef(conn) virObjectUnref(conn) The latter returns a true value, if the object has been freed (ie its ref count hit zero) Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-07-11 13:35:44 +00:00
# virobject.h
virClassName;
virClassNew;
virObjectFreeCallback;
virObjectIsClass;
virObjectNew;
virObjectRef;
virObjectUnref;
# virpidfile.h
virPidFileAcquire;
virPidFileAcquirePath;
virPidFileBuildPath;
virPidFileRead;
virPidFileReadIfAlive;
virPidFileReadPath;
virPidFileReadPathIfAlive;
virPidFileRelease;
virPidFileReleasePath;
virPidFileWrite;
virPidFileWritePath;
virPidFileDelete;
virPidFileDeletePath;
# virprocess.h
virProcessAbort;
virProcessKill;
virProcessKillPainfully;
virProcessTranslateStatus;
virProcessWait;
# virrandom.h
virRandom;
virRandomBits;
virRandomGenerateWWN;
virRandomInt;
# virsocketaddr.h
virSocketAddrBroadcast;
virSocketAddrBroadcastByPrefix;
virSocketAddrCheckNetmask;
virSocketAddrEqual;
virSocketAddrFormat;
virSocketAddrFormatFull;
virSocketAddrGetPort;
virSocketAddrGetRange;
virSocketAddrIsNetmask;
virSocketAddrIsPrivate;
virSocketAddrMask;
virSocketAddrMaskByPrefix;
virSocketAddrParse;
virSocketAddrParseIPv4;
virSocketAddrParseIPv6;
virSocketAddrPrefixToNetmask;
virSocketAddrSetIPv4Addr;
virSocketAddrSetPort;
# virterror_internal.h
virDispatchError;
virErrorInitialize;
virRaiseErrorFull;
virReportErrorHelper;
virReportOOMErrorFull;
virReportSystemErrorFull;
virSetError;
virSetErrorLogPriorityFunc;
virStrerror;
# virstring.h
virStringSplit;
virStringJoin;
virStringFreeList;
# virtime.h
virTimeFieldsNow;
virTimeFieldsNowRaw;
virTimeFieldsThen;
virTimeFieldsThenRaw;
virTimeMillisNow;
virTimeMillisNowRaw;
virTimeStringNow;
virTimeStringNowRaw;
virTimeStringThen;
virTimeStringThenRaw;
# virtypedparam.h
virTypedParameterArrayClear;
virTypedParameterArrayValidate;
virTypedParameterAssign;
virTypedParameterAssignFromStr;
# viruri.h
virURIFormat;
virURIFormatParams;
virURIFree;
virURIParse;
# xml.h
virXMLChildElementCount;
virXMLParseHelper;
virXMLPickShellSafeComment;
virXMLPropString;
virXMLSaveFile;
virXPathBoolean;
virXPathInt;
virXPathLong;
virXPathLongHex;
virXPathLongLong;
virXPathNode;
virXPathNodeSet;
virXPathNumber;
virXPathString;
virXPathStringLimit;
virXPathUInt;
virXPathULong;
virXPathULongHex;
virXPathULongLong;