- 28 9月, 2012 10 次提交
-
-
由 Daniel P. Berrange 提交于
The 'const char *category' parameter only has a few possible values now that the filename has been separated. Turn this parameter into an enum instead. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the logging APIs have a 'const char *category' parameter which indicates where the log message comes from. This is typically a combination of the __FILE__ string and other prefix. Split the __FILE__ off into a dedicated parameter so it can passed to the log outputs Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
General whitespace cleanup in the logging files - Move '{' to a new line after funtion declaration - Put each parameter on a new line to avoid long lines - Put return type on new line - Leave 2 blank lines between functions Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The log destinations are an enum, but most of the code was just using a plain 'int' for function params / variables. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The __LINE__ macro value is specified to fit in the size_t type, so use that instead of 'long long' in the logging code Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The log priority levels are an enum, but most of the code was just using a plain 'int' for function params / variables. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Guannan Ren 提交于
The result is indeterminate for NULL argument to python functions as follows. It's better to return negative value in these situations. PyObject_IsTrue will segfault if the argument is NULL PyFloat_AsDouble(NULL) is -1.000000 PyLong_AsUnsignedLongLong(NULL) is 0.000000
-
由 Benjamin Cama 提交于
I hit this problem recently when trying to create a bridge with an IPv6 address on a 3.2 kernel: dnsmasq (and, further, radvd) would not bind to the given address, waiting 20s and then giving up with -EADDRNOTAVAIL (resp. exiting immediately with "error parsing or activating the config file", without libvirt noticing it, BTW). This can be reproduced with (I think) any kernel >= 2.6.39 and the following XML (to be used with "virsh net-create"): <network> <name>test-bridge</name> <bridge name='testbr0' /> <ip family='ipv6' address='fd00::1' prefix='64'> </ip> </network> (it happens even when you have an IPv4, too) The problem is that since commit [1] (which, ironically, was made to “help IPv6 autoconfiguration”) the linux bridge code makes bridges behave like “real” devices regarding carrier detection. This makes the bridges created by libvirt, which are started without any up devices, stay with the NO-CARRIER flag set, and thus prevents DAD (Duplicate address detection) from happening, thus letting the IPv6 address flagged as “tentative”. Such addresses cannot be bound to (see RFC 2462), so dnsmasq fails binding to it (for radvd, it detects that "interface XXX is not RUNNING", thus that "interface XXX does not exist, ignoring the interface" (sic)). It seems that this behavior was enhanced somehow with commit [2] by avoiding setting NO-CARRIER on empty bridges, but I couldn't reproduce this behavior on my kernel. Anyway, with the “dummy tap to set MAC address” trick, this wouldn't work. To fix this, the idea is to get the bridge's attached device to be up so that DAD can happen (deactivating DAD altogether is not a good idea, I think). Currently, libvirt creates a dummy TAP device to set the MAC address of the bridge, keeping it down. But even if we set this device up, it is not RUNNING as soon as the tap file descriptor attached to it is closed, thus still preventing DAD. So, we must modify the API a bit, so that we can get the fd, keep the tap device persistent, run the daemons, and close it after DAD has taken place. After that, the bridge will be flagged NO-CARRIER again, but the daemons will be running, even if not happy about the device's state (but we don't really care about the bridge's daemons doing anything when no up interface is connected to it). Other solutions that I envisioned were: * Keeping the *-nic interface up: this would waste an fd for each bridge during all its life. May be acceptable, I don't really know. * Stop using the dummy tap trick, and set the MAC address directly on the bridge: it is possible since quite some time it seems, even if then there is the problem of the bridge not being RUNNING when empty, contrary to what [2] says, so this will need fixing (and this fix only happened in 3.1, so it wouldn't work for 2.6.39) * Using the --interface option of dnsmasq, but I saw somewhere that it's not used by libvirt for backward compatibility. I am not sure this would solve this problem, though, as I don't know how dnsmasq binds itself to it with this option. This is why this patch does what's described earlier. This patch also makes radvd start even if the interface is “missing” (i.e. it is not RUNNING), as it daemonizes before binding to it, and thus sometimes does it after the interface has been brought down by us (by closing the tap fd), and then originally stops. This also makes it stop yelling about it in the logs when the interface is down at a later time. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1faa4356a3bd89ea11fb92752d897cff3a20ec0e [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=b64b73d7d0c480f75684519c6134e79d50c1b341
-
由 Daniel P. Berrange 提交于
If QEMU reports CommandNotFound for the 'query-events' command, we must treat that as success, returning a zero-length array of events Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Jim Fehlig 提交于
In Xen 4.2, xs.h is deprecated in favor of xenstore.h. xs.h now contains #warning xs.h is deprecated use xenstore.h instead #include <xenstore.h> which fails compilation when warnings are treated as errors. Introduce a configure-time check for xenstore.h and if found, use it instead of xs.h.
-
- 27 9月, 2012 30 次提交
-
-
由 Miloslav Trmač 提交于
In addition to the preformatted text line, pass the raw message as well, to allow the output functions to use a different output format. Signed-off-by: NMiloslav Trmač <mitr@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Miloslav Trmač 提交于
Allow for the code converting from libvirt log levels to syslog log levels to be reused. Signed-off-by: NMiloslav Trmač <mitr@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The qemu monitor does not require qemu_conf.h, and the qemu capabilities code actually wants bitmap.h Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetTargetArch() method to support invocation of the 'query-target' JSON monitor command. No HMP equivalent is required, since this will only be present for QEMU >= 1.2 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetObjectProps() method to support invocation of the 'device-list-properties' JSON monitor command. No HMP equivalent is required, since this will only be present for QEMU >= 1.2 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetObjectTypes() method to support invocation of the 'qom-list-types' JSON monitor command. No HMP equivalent is required, since this will only be present for QEMU >= 1.2 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetEvents() method to support invocation of the 'query-events' JSON monitor command. No HMP equivalent is required, since this will only be used when JSON is available The existing qemuMonitorJSONCheckEvents() method is refactored to use this new method Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetCPUCommands() method to support invocation of the 'query-commands' JSON monitor command. No HMP equivalent is required, since this will only be used when JSON is available The existing qemuMonitorJSONCheckCommands() method is refactored to use this new method Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetCPUDefinitions() method to support invocation of the 'query-cpu-definitions' JSON monitor command. No HMP equivalent is required, since this will only be present for QEMU >= 1.2 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetMachines() method to support invocation of the 'query-machines' JSON monitor command. No HMP equivalent is required, since this will only be present for QEMU >= 1.2 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Add a new qemuMonitorGetVersion() method to support invocation of the 'query-version' JSON monitor command. No HMP equivalent is provided, since this will only be used for QEMU >= 1.2 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The qemuCapsProbeMachineTypes & qemuCapsProbeCPUModels methods do not need to be invoked directly anymore. Make them static and refactor them to directly populate the qemuCapsPtr object Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When launching a QEMU guest the binary is probed to discover the list of supported CPU names. Remove this probing with a simple lookup of CPU models in the qemuCapsPtr object. This avoids another invocation of the QEMU binary during the startup path. As a nice benefit we can now remove all the nasty hacks from the test suite which were done to avoid having to exec QEMU on the test system. The building of the -cpu command line can just rely on data we pre-populate in qemuCapsPtr. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When XML for a new guest is received, the machine type is immediately canonicalized into the version specific name. This involves probing QEMU for supported machine types. Replace this probing with a lookup of the machine types in the (hopefully cached) qemuCapsPtr object Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Remove all use of the existing APIs for querying QEMU capability flags. Instead obtain a qemuCapsPtr object from the global cache. This avoids the execution of 'qemu -help' (and related commands) when launching new guests. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
For historical compat we use 'itanium' as the arch name, so if the QEMU binary suffix is 'ia64' we need to translate it Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If the qemuAgentClose method is called from a place which holds the domain lock, it is theoretically possible to get a deadlock in the agent destroy callback. This has not been observed, but the equivalent code in the QEMU monitor destroy callback has seen a deadlock. Remove the redundant locking while unrefing the object and the bogus assignment Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Many parts of virDomainDefPtr were using 'int' variables as array length counts. Replace all these with size_t and update various format strings & API signatures to adapt Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Some users report (very rarely) seeing a deadlock in the QEMU monitor callbacks Thread 10 (Thread 0x7fcd11e20700 (LWP 26753)): #0 0x00000030d0e0de4d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00000030d0e09ca6 in _L_lock_840 () from /lib64/libpthread.so.0 #2 0x00000030d0e09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007fcd162f416d in virMutexLock (m=<optimized out>) at util/threads-pthread.c:85 #4 0x00007fcd1632c651 in virDomainObjLock (obj=<optimized out>) at conf/domain_conf.c:14256 #5 0x00007fcd0daf05cc in qemuProcessHandleMonitorDestroy (mon=0x7fcccc0029e0, vm=0x7fcccc00a850) at qemu/qemu_process.c:1026 #6 0x00007fcd0db01710 in qemuMonitorDispose (obj=0x7fcccc0029e0) at qemu/qemu_monitor.c:249 #7 0x00007fcd162fd4e3 in virObjectUnref (anyobj=<optimized out>) at util/virobject.c:139 #8 0x00007fcd0db027a9 in qemuMonitorClose (mon=<optimized out>) at qemu/qemu_monitor.c:860 #9 0x00007fcd0daf61ad in qemuProcessStop (driver=driver@entry=0x7fcd04079d50, vm=vm@entry=0x7fcccc00a850, reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED, flags=flags@entry=0) at qemu/qemu_process.c:4057 #10 0x00007fcd0db323cf in qemuDomainDestroyFlags (dom=<optimized out>, flags=<optimized out>) at qemu/qemu_driver.c:1977 #11 0x00007fcd1637ff51 in virDomainDestroyFlags ( domain=domain@entry=0x7fccf00c1830, flags=1) at libvirt.c:2256 At frame #10 we are holding the domain lock, we call into qemuProcessStop() to cleanup QEMU, which triggers the monitor to close, which invokes qemuProcessHandleMonitorDestroy() which tries to obtain the domain lock again. This is a non-recursive lock, hence hang. Since qemuMonitorPtr is a virObject, the unref call in qemuProcessHandleMonitorDestroy no longer needs mutex protection. The assignment of priv->mon = NULL, can be instead done by the caller of qemuMonitorClose(), thus removing all need for locking. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If QEMU quits immediately after we opened the monitor it was possible we would skip the clearing of the SELinux process socket context Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
In the cgroups APIs we have a virCgroupKillPainfully function which does the loop sending SIGTERM, then SIGKILL and waiting for the process to exit. There is similar functionality for simple processes in qemuProcessKill, but it is tangled with the QEMU code. Untangle it to provide a virProcessKillPainfuly function Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
When calling qemuProcessKill from the virDomainDestroy impl in QEMU, do not ignore the return value. This ensures that if QEMU fails to respond to SIGKILL, the caller will know about the failure. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Depending on the scenario in which LXC containers exit, it is possible for the EOF callback of the LXC monitor to deadlock the driver. #0 0x00000038a0a0de4d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038a0a09ca6 in _L_lock_840 () from /lib64/libpthread.so.0 #2 0x00000038a0a09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f4bd9579d55 in virMutexLock (m=<optimized out>) at util/threads-pthread.c:85 #4 0x00007f4bcacc7597 in lxcDriverLock (driver=0x7f4bc40c8290) at lxc/lxc_conf.h:81 #5 virLXCProcessMonitorEOFNotify (mon=<optimized out>, vm=0x7f4bb4000b00) at lxc/lxc_process.c:581 #6 0x00007f4bd9645c91 in virNetClientCloseLocked (client=client@entry=0x7f4bb4009e60) at rpc/virnetclient.c:554 #7 0x00007f4bd96460f8 in virNetClientIOEventLoopPassTheBuck (thiscall=0x0, client=0x7f4bb4009e60) at rpc/virnetclient.c:1306 #8 virNetClientIOEventLoopPassTheBuck (client=0x7f4bb4009e60, thiscall=0x0) at rpc/virnetclient.c:1287 #9 0x00007f4bd96467a2 in virNetClientCloseInternal (reason=3, client=0x7f4bb4009e60) at rpc/virnetclient.c:589 #10 virNetClientCloseInternal (client=0x7f4bb4009e60, reason=3) at rpc/virnetclient.c:561 #11 0x00007f4bcacc4a82 in virLXCMonitorClose (mon=0x7f4bb4000a00) at lxc/lxc_monitor.c:201 #12 0x00007f4bcacc55ac in virLXCProcessCleanup (reason=<optimized out>, vm=0x7f4bb4000b00, driver=0x7f4bc40c8290) at lxc/lxc_process.c:240 #13 virLXCProcessStop (driver=0x7f4bc40c8290, vm=vm@entry=0x7f4bb4000b00, reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED) at lxc/lxc_process.c:735 #14 0x00007f4bcacc5bd2 in virLXCProcessAutoDestroyDom (payload=<optimized out>, name=0x7f4bb4003c80, opaque=0x7fff41af2df0) at lxc/lxc_process.c:94 #15 0x00007f4bd9586649 in virHashForEach (table=0x7f4bc409b270, iter=iter@entry=0x7f4bcacc5ab0 <virLXCProcessAutoDestroyDom>, data=data@entry=0x7fff41af2df0) at util/virhash.c:514 #16 0x00007f4bcacc52d7 in virLXCProcessAutoDestroyRun (driver=driver@entry=0x7f4bc40c8290, conn=conn@entry=0x7f4bb8000ab0) at lxc/lxc_process.c:120 #17 0x00007f4bcacca628 in lxcClose (conn=0x7f4bb8000ab0) at lxc/lxc_driver.c:128 #18 0x00007f4bd95e67ab in virReleaseConnect (conn=conn@entry=0x7f4bb8000ab0) at datatypes.c:114 When the driver calls virLXCMonitorClose, there is really no need for the EOF callback to be invoked in this case, since the caller can easily handle events itself. In changing this, the monitor needs to take a deep copy of the callback list, not merely a reference. Also adds debug statements in various places to aid troubleshooting Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Jim Fehlig 提交于
Xen upstream c/s 24102:dc8e55c9 bumped the sysctl version to 9. Support this sysctl version in the xen_hypervisor sub-driver.
-
由 Laine Stump 提交于
<interface> elements are location inside the <forward> element of a network. There is only one <forward> element in any network, but it might have many <interface> elements. This element only contains a single attribute, "dev", which is the name of a network device (e.g. "eth0"). Since there is only a single attribute, the modify operation isn't supported for this "section", only add-first, add-last, and delete. Also, note that it's not permitted to delete an interface from the list while any guest is using it. We may later decide this is safe (because removing it from the list really only excludes it from consideration in future guest allocations of interfaces, but doesn't affect any guests currently connected), but for now this limitation seems prudent (of course when changing the persistent config, this limitation doesn't apply, because the persistent config doesn't support the concept of "in used"). Another limitation - it is also possible for the interfraces in this list to be described by PCI address rather than netdev name. However, I noticed while writing this function that we currently don't support defining interfaces that way in config - the only method of getting interfaces specified as <adress type='pci' ..../> instead of <interface dev='xx'/> is to provide a <pf dev='yy'/> element under forward, and let the entries in the interface list be automatically populated with the virtual functions (VF) of the physical function device given in <pg>. As with the other virNetworkUpdate section backends, support for this section is completely contained within a single static function, no other changes were required, and only functions already called from elsewhere within the same file are used in the new content for this existing function (i.e., adding this code should not cause a new build problem on any platform).
-