- 29 8月, 2015 1 次提交
-
-
由 Jim Fehlig 提交于
This reverts commit 1ce7c1d2, which introduced a significant semantic change to the virDomainGetInfo() API. Additionally, the change was only made to 2 of the 15 virt drivers. Conflicts: src/qemu/qemu_driver.c Signed-off-by: NJim Fehlig <jfehlig@suse.com> (cherry picked from commit 60acb38a)
-
- 02 7月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
So, recently I was testing the LXC driver. You know, startup some domains. But to my surprise, I was not able to start a single one: virsh # start --console test error: Reconnected to the hypervisor error: Failed to start domain test error: internal error: guest failed to start: unexpected exit status 125 So I've start digging. It turns out, that in virExec(), when I printed out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not valid FD number: it has random value of several millions. This obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611). But outfdptr is set in virCommandSetOutputFD(). The only place within LXC driver where the function is called is in virLXCProcessBuildControllerCmd(). If you take a closer look at the function it looks like this: static virCommandPtr virLXCProcessBuildControllerCmd(virLXCDriverPtr driver, .. int logfd, const char *pidfile) { ... virCommandSetOutputFD(cmd, &logfd); virCommandSetErrorFD(cmd, &logfd); ... } Yes, you guessed it. @logfd is passed into the function by value. However, in the function we try to get its address (an address of a local variable) which is no longer valid once function is finished and stack is cleaned. Therefore when cmd->outfdptr is evaluated at any point after this function, we may get a random number, depending on what's currently on the stack. Of course, this may work sometimes too - it depends on the compiler how it arranges the code, when the stack is wiped out. In order to fix this, lets pass a pointer to @logfd instead of figuring out (wrong) its value in a function. The bug was introduced in e1de5521. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 302146b1)
-
- 17 6月, 2015 1 次提交
-
-
由 Eric W. Biederman 提交于
Future kernels will mandate the use of nosuid+nodev+noexec flags when mounting the /proc/sys filesystem. Unconditionally add them now since they don't harm things regardless and could mitigate future security attacks. (cherry picked from commit 24710414)
-
- 06 6月, 2015 2 次提交
-
-
由 Lubomir Rintel 提交于
There was a couple of problems with the style fixes applied to the original patch: 1.) virFileReadAllQuiet comparison was incorrectly parenthesized when moved into a condition, causing the len to be set to the result of comparison. This, together with the removed underflow check would underflow the phy buffer. 2.) The logic was broken. Failure to call "ip" would abort the function, thus the "iw" branch would never be reached. This aims to fix the issues and work around possible style complains :) Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> (cherry picked from commit 81b19ce4)
-
由 Lubomir Rintel 提交于
It's not a problem at all and causes virt-manager to break down. Note: netcf 0.2.8 and earlier generates invalid XML for a bond with no interfaces anyway, so in that case this error in libvirt is never reached since we fail earlier. Signed-off-by: NLubomir Rintel <lkundrak@v3.sk> (cherry picked from commit efc68de5)
-
- 28 5月, 2015 6 次提交
-
-
由 Lubomir Rintel 提交于
Upping an interface for no reason and not configuring it is a cardinal sin. With the default addrgenmode if eui64 it sticks a link-local address to the interface. That is not good, as NetworkManager would see an address configured, assume the interface is already configured and won't touch it iself and the interface might stay unconfigured until the end of the days. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1124721Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit c3cf3c43)
-
由 Michal Privoznik 提交于
In one of my previous commits (49ed6cff) I've introduced a test among with some files stored under virnetdevtestdata folder. While this works perfectly within a git tree, the folder was not getting into .tar.gz and therefore the dist-check would fail. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 598f3fdd)
-
由 Lubomir Rintel 提交于
The 802.11 interfaces can not be moved by themselves, their Phy has to move too. If there are other interfaces, they have to move too -- hopefully it's not too confusing. This is a less-invasive alternative to defining a new hostdev type for PHYs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 3a495948)
-
由 Michal Privoznik 提交于
Throughout the code, we have several places need to construct a path somewhere in /sys/class/net/... They are not consistent and nearly each code piece invents its own way how to do it. So unify this by: 1) use virNetDevSysfsFile() wherever possible 2) At least use common macro SYSFS_NET_DIR declared in virnetdev.h at the rest of places which can't go with 1) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 96a21e97)
-
由 Michal Privoznik 提交于
This is yet another test for check of basic functionality of our NIC state handling code. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 49ed6cff)
-
由 Eric Blake 提交于
Commit 49ed6cff is broken on mingw and other non-linux platforms: CCLD libvirt.la Cannot export virNetDevSysfsFile: symbol not defined collect2: error: ld returned 1 exit status * src/util/virnetdev.c: Provide virNetDevSysfsFile fallback. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 58dfc534)
-
- 28 4月, 2015 29 次提交
-
-
由 Cole Robinson 提交于
-
由 Jiri Denemark 提交于
==26726== by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80) ==26726== by 0x5673605: UnknownInlinedFun (stdio2.h:210) ==26726== by 0x5673605: virVasprintfInternal (virstring.c:476) ==26726== by 0x56736EE: virAsprintfInternal (virstring.c:497) ==26726== by 0x5680C37: virGetUserRuntimeDirectory (virutil.c:866) ==26726== by 0x5783A89: virNetSocketNewConnectUNIX (virnetsocket.c:572) ==26726== by 0x57751AF: virNetClientNewUNIX (virnetclient.c:344) ==26726== by 0x57689B3: doRemoteOpen (remote_driver.c:895) ==26726== by 0x5769F8E: remoteConnectOpen (remote_driver.c:1195) ==26726== by 0x57092DF: do_open (libvirt.c:1189) ==26726== by 0x570A7BF: virConnectOpenAuth (libvirt.c:1341) https://bugzilla.redhat.com/show_bug.cgi?id=1215042Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit da4d7c30)
-
由 Daniel P. Berrange 提交于
The PortNumber data type is declared to derive from 'short'. Unfortunately this is an signed type, so validates the range [-32,768, 32,767] which excludes valid port numbers between 32767 and 65535. We can't use 'unsignedShort', since we need -1 to be a valid port number too. This change is to use 'int' and set an explicit max boundary instead of relying on the data types' built-in max. One of the existing tests is changed to use a high port number to validate the schema. https://bugzilla.redhat.com/show_bug.cgi?id=1214664Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 615bdfda)
-
由 zhang bo 提交于
just as what b8e25c35 did, we fall back to the ACPI method when the guest agent is unresponsive in qemuDomainReboot(). Signed-off-by: NYueWenyuan <yuewenyuan@huawei.com> Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit eadf41fe)
-
由 Roman Bogorodskiy 提交于
When running on FreeBSD, there's a bug in virCommandProcessIO polling that is triggered by the commandtest. A test that triggers EPIPE in commandtest (named "test20") hungs forever on FreeBSD. Apparently, this happens because FreeBSD sets POLLHUP flag on revents when stdin in closed. And as the current implementation only checks for POLLOUT and POLLERR, it ends up looping forever inside virCommandProcessIO and not trying to do one more write() that would trigger EPIPE. To fix that check for the POLLHUP flag along with POLLOUT and POLLERR. (cherry picked from commit e34cccf7)
-
由 Peter Krempa 提交于
Some storage protocols allow to have the @path field in struct virStorageSource set to NULL. Add NULLSTR() wrappers to handle this possibility until I finish the storage source error formatter. (cherry picked from commit 62a61d58)
-
由 Laine Stump 提交于
A further fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1113474 Since there is no possibility that any type of macvtap will work if the parent physdev it's attached to is offline, we should bring the physdev online at the same time as the macvtap. When taking the macvtap offline, it's also necessary to take the physdev offline for macvtap passthrough mode (because the physdev has the same MAC address as the macvtap device, so could potentially cause problems with misdirected packets during migration, as outlined in commits 829770 and 879c13). We can't set the physdev offline for other macvtap modes 1) because there may be other macvtap devices attached to the same physdev (and/or the host itself may be using the device) in the other modes whereas passthrough mode is exclusive to one macvtap at a time, and 2) there's no practical reason to do so anyway. (cherry picked from commit 38172ed8)
-
由 Laine Stump 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1113474 When we set the MAC address of a network device as a part of setting up macvtap "passthrough" mode (where the domain has an emulated netdev connected to a host macvtap device that has exclusive use of the physical device, and sets the device MAC address to match its own, i.e. "<interface type='direct'> <source mode='passthrough' .../>"), we use ioctl(SIOCSIFHWADDR) giving it the name of that device. This is true even if it is an SRIOV Virtual Function (VF). But, when we are setting the MAC address / vlan ID of a VF in preparation for "hostdev network" passthrough (this is where we set the MAC address and vlan id of the VF after detaching the host net driver and before assigning the device to the domain with PCI passthrough, i.e. "<interface type='hostdev'>", we do the setting via a netlink RTM_SETLINK message for that VF's Physical Function (PF), telling it the VF# we want to change. This sets an "administratively changed MAC" flag for that VF in the PF's driver, and from that point on (until the PF driver is reloaded, *not* merely the VF driver) that VF's MAC address can't be changed using ioctl(SIOCSIFHWADDR) - the only way to change it is via the PF with RTM_SETLINK. This means that if a VF is used for hostdev passthrough, it will have the admin flag set, and future attempts to use that VF for macvtap passthrough will fail. The solution to this problem is to check if the device being used for macvtap passthrough is actually a VF; if so, we use the netlink RTM_SETLINK message to the PF to set the VF's mac address instead of ioctl(SIOCSIFHWADDR) directly to the VF; if not, behavior does not change from previously. There are three pieces to making this work: 1) virNetDevMacVLan(Create|Delete)WithVPortProfile() now call virNetDev(Replace|Restore)NetConfig() rather than virNetDev(Replace|Restore)MacAddress() (simply passing -1 for VF# and vlanid). 2) virNetDev(Replace|Restore)NetConfig() check to see if the device is a VF. If so, they find the PF's name and VF#, allowing them to call virNetDev(Replace|Restore)VfConfig(). 3) To prevent mixups when detaching a macvtap passthrough device that had been attached while running an older version of libvirt, virNetDevRestoreVfConfig() is potentially given the preserved name of the VF, and if the proper statefile for a VF can't be found in the stateDir (${stateDir}/${pfname}_vf${vfid}), virNetDevRestoreMacAddress() is called instead (which will look in the file named ${stateDir}/${vfname}). This problem has existed in every version of libvirt that has both macvtap passthrough and interface type='hostdev'. Fortunately people seem to use one or the other though, so it hasn't caused any real world problem reports. (cherry picked from commit cb3fe38c)
-
由 Richard W.M. Jones 提交于
Commit 70f44663 (from 2008) introduced some functions for testing whether xend was returning correct sound models. Those functions have long gone, but the function prototypes remain. This commit removes the unused prototypes. Signed-off-by: NRichard W.M. Jones <rjones@redhat.com> (cherry picked from commit 093eea95)
-
由 zhang bo 提交于
When a qemu domain is to be rebooted, from outside, at libvirt level it looks like regular shutdown. To really restart the domain, libvirt needs to issue reset command on the monitor once SHUTDOWN event appeared. So, in order to differentiate bare shutdown and reboot libvirt uses a variable within domain private data. It's called fakeReboot. When the reboot API is called, the variable is set, but when the shutdown API is called it must be cleared out. But it was not for every possible case. So if user called virDomainReboot(), and there was no ACPI daemon running inside the guest (so guest didn't initiated shutdown sequence) and then virDomainShutdown(mode=agent) was called bad thing happened. We remembered the fakeReboot and instead of shutting the domain down, we just rebooted it. Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NWang Yufei <james.wangyufei@huawei.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 8be502fd)
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1211436 This reverts commit b7829f95. The previous fix was not correct. Like everywhere else, a driver is a global variable allocated in stateInitialize function (or something similar for stateless drivers). Later, when a driver API is called, it's possible that the global variable is accessed and dereferenced. Now, some drivers require root privileges because they undertake some actions reserved only for the system admin (e.g. manipulating host firewall). And here's the trouble, the NWFilter state initializer exited too early when finding out it's running unprivileged, leaving the global NWFilter driver variable uninitialized. Any subsequent API call that tried to lock the driver resulted in dereferencing the driver and thus crash. On the other hand, in order to not resurrect the bug the original commit was fixing, Let's forbid the nwfilter define in session mode. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Conflicts: src/nwfilter/nwfilter_driver.c: Context. Code changed a bit since 2013. (cherry picked from commit 77d92e2e)
-
由 Michal Privoznik 提交于
There is a possibility that we jump onto error label with @lockpath still initialized to NULL. Here, the @lockpath should be unlink()-ed, but passing there a NULL is not a good idea. Don't do that. In fact, we should call unlink() only if we created the lock file successfully. Reported-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 1fdac3d9)
-
由 Jiri Denemark 提交于
When acquiring resource via sanlock fails, we would report it as VIR_ERR_INTERNAL_ERROR, which is not very friendly to applications using libvirt. Moreover, the lockd driver would report the same failure as VIR_ERR_RESOURCE_BUSY, which looks better. Unfortunately, in sanlock driver we don't really know if acquiring the resource failed because it was already locked or there was another reason behind. But the end result is the same and I think using VIR_ERR_RESOURCE_BUSY reason for all acquire failures is still better than what we have now. https://bugzilla.redhat.com/show_bug.cgi?id=1165119Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 4864e377)
-
由 Michal Privoznik 提交于
When pre-creating storage for domains, we need to find corresponding disk in the XML on the destination (domain XML may differ there, e.g. disk is accessible under different path). For better debugging, I'm printing all info I received on a disk. But there was a typo when printing the disk capacity: "%lluu" instead of "%llu". Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 65a88572)
-
由 Xing Lin 提交于
The problem with the previous implementation is, even when qemuMigrationUpdateJobStatus() detects a migration job has completed, it will do a sleep for 50 ms (which is unnecessary and only adds up to the VM pause time). Signed-off-by: NXing Lin <xinglin@cs.utah.edu> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 522e81cb)
-
由 Michael Chapman 提交于
Currently we check qemuCaps before starting the block job. But qemuCaps isn't available on a stopped domain, which means we get a misleading error message in this case: # virsh domstate example shut off # virsh blockjob example vda error: unsupported configuration: block jobs not supported with this QEMU binary Move the qemuCaps check into the block job so that we are guaranteed the domain is running. Signed-off-by: NMichael Chapman <mike@very.puzzling.org> (cherry picked from commit cfcdf5ff)
-
由 Michael Chapman 提交于
qemuMigrationCookieAddNBD is usually called from within an async MIGRATION_OUT or MIGRATION_IN job, so it needs to start a nested job. (The one exception is during the Begin phase when change protection isn't enabled, but qemuDomainObjEnterMonitorAsync will behave the same as qemuDomainObjEnterMonitor in this case.) This bug was encountered with a libvirt client that repeatedly queries the disk mirroring block job info during a migration. If one of these queries occurs just as the Perform migration cookie is baked, libvirt crashes. Relevant logs are as follows: 6701: warning : qemuDomainObjEnterMonitorInternal:1544 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous [1] 6701: info : qemuMonitorSend:972 : QEMU_MONITOR_SEND_MSG: mon=0x7fefdc004700 msg={"execute":"query-block","id":"libvirt-629"} [2] 6699: info : qemuMonitorIOWrite:503 : QEMU_MONITOR_IO_WRITE: mon=0x7fefdc004700 buf={"execute":"query-block","id":"libvirt-629"} [3] 6704: info : qemuMonitorSend:972 : QEMU_MONITOR_SEND_MSG: mon=0x7fefdc004700 msg={"execute":"query-block-jobs","id":"libvirt-630"} [4] 6699: info : qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_REPLY: mon=0x7fefdc004700 reply={"return": [...], "id": "libvirt-629"} 6699: error : qemuMonitorJSONIOProcessLine:211 : internal error: Unexpected JSON reply '{"return": [...], "id": "libvirt-629"}' At [1] qemuMonitorBlockStatsUpdateCapacity sends its request, then waits on mon->notify. At [2] the request is written out to the monitor socket. At [3] qemuMonitorBlockJobInfo sends its request, and also waits on mon->notify. The reply from the first request is received at [4]. However, qemuMonitorJSONIOProcessLine is not expecting this reply since the second request hadn't completed sending. The reply is dropped and an error is returned. qemuMonitorIO signals mon->notify twice during its error handling, waking up both of the threads waiting on it. One of them clears mon->msg as it exits qemuMonitorSend; the other crashes: qemuMonitorSend (mon=0x7fefdc004700, msg=<value optimized out>) at qemu/qemu_monitor.c:975 975 while (!mon->msg->finished) { (gdb) print mon->msg $1 = (qemuMonitorMessagePtr) 0x0 Signed-off-by: NMichael Chapman <mike@very.puzzling.org> (cherry picked from commit 72df8314)
-
由 Michael Chapman 提交于
The close callbacks hash are keyed by a UUID-string, but virCloseCallbacksRun was attempting to remove them by raw UUID. This patch ensures the callback entries are removed by UUID-string as well. This bug caused problems when guest migrations were abnormally aborted: # timeout --signal KILL 1 \ virsh migrate example qemu+tls://remote/system \ --verbose --compressed --live --auto-converge \ --abort-on-error --unsafe --persistent \ --undefinesource --copy-storage-all --xml example.xml Killed # virsh migrate example qemu+tls://remote/system \ --verbose --compressed --live --auto-converge \ --abort-on-error --unsafe --persistent \ --undefinesource --copy-storage-all --xml example.xml error: Requested operation is not valid: domain 'example' is not being migrated Signed-off-by: NMichael Chapman <mike@very.puzzling.org> (cherry picked from commit fa2607d5)
-
由 Michael Chapman 提交于
If a VM migration is aborted, a disk mirror may be failed by QEMU before libvirt has a chance to cancel it. The disk->mirrorState remains at _ABORT in this case, and this breaks subsequent mirrorings of that disk. We should instead check the mirrorState directly and transition to _NONE if it is already aborted. Do the check *after* aborting the block job in QEMU to avoid a race. Signed-off-by: NMichael Chapman <mike@very.puzzling.org> (cherry picked from commit e5d729ba)
-
由 Michael Chapman 提交于
If virCloseCallbacksSet fails, qemuMigrationBegin must return NULL to indicate an error occurred. Signed-off-by: NMichael Chapman <mike@very.puzzling.org> (cherry picked from commit 77ddd0bb)
-
由 Michael Chapman 提交于
The destination libvirt daemon in a migration may segfault if the client disconnects immediately after the migration has begun: # virsh -c qemu+tls://remote/system list --all Id Name State ---------------------------------------------------- ... # timeout --signal KILL 1 \ virsh migrate example qemu+tls://remote/system \ --verbose --compressed --live --auto-converge \ --abort-on-error --unsafe --persistent \ --undefinesource --copy-storage-all --xml example.xml Killed # virsh -c qemu+tls://remote/system list --all error: failed to connect to the hypervisor error: unable to connect to server at 'remote:16514': Connection refused The crash is in: 1531 void 1532 qemuDomainObjEndJob(virQEMUDriverPtr driver, virDomainObjPtr obj) 1533 { 1534 qemuDomainObjPrivatePtr priv = obj->privateData; 1535 qemuDomainJob job = priv->job.active; 1536 1537 priv->jobs_queued--; Backtrace: #0 at qemuDomainObjEndJob at qemu/qemu_domain.c:1537 #1 in qemuDomainRemoveInactive at qemu/qemu_domain.c:2497 #2 in qemuProcessAutoDestroy at qemu/qemu_process.c:5646 #3 in virCloseCallbacksRun at util/virclosecallbacks.c:350 #4 in qemuConnectClose at qemu/qemu_driver.c:1154 ... qemuDomainRemoveInactive calls virDomainObjListRemove, which in this case is holding the last remaining reference to the domain. qemuDomainRemoveInactive then calls qemuDomainObjEndJob, but the domain object has been freed and poisoned by then. This patch bumps the domain's refcount until qemuDomainRemoveInactive has completed. We also ensure qemuProcessAutoDestroy does not return the domain to virCloseCallbacksRun to be unlocked in this case. There is similar logic in bhyveProcessAutoDestroy and lxcProcessAutoDestroy (which call virDomainObjListRemove directly). Signed-off-by: NMichael Chapman <mike@very.puzzling.org> (cherry picked from commit 7578cc17)
-
由 Peter Krempa 提交于
The block copy API takes the speed in bytes/s rather than MiB/s that was the prior approach in virDomainBlockRebase. We correctly converted the speed to bytes/s in the old API but we still called the common helper virDomainBlockCopyCommon with the unadjusted variable. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1207122 (cherry picked from commit 3c6a72d5)
-
由 Luyao Huang 提交于
The overflow check for the bandwidth parameter did not jump to the cleanup label. Additionally virsh should use vshError instead of virReportError. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206987Signed-off-by: NLuyao Huang <lhuang@redhat.com> (cherry picked from commit 390f218b)
-
由 Shanzhi Yu 提交于
Blockcopy to non-file destination is not supported according the code, but a 'goto endjob' is missed after checking the destination. This leads to calling drive-mirror with wrong parameters. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1206406Signed-off-by: NShanzhi Yu <shyu@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com> (cherry picked from commit c5fbad66)
-
由 Wei Huang 提交于
Current libvirt can only handle up to 1023 bytes when it reads Linux sysfs topology/thread_siblings. This isn't enough for Linux distributions that support a large value. This patch fixes the problem by using VIR_ALLOC()/VIR_FREE(), instead of using a fixed-size (1024) local char array. In the meanwhile SYSFS_THREAD_SIBLINGS_LIST_LENGTH_MAX is increased to 8192 which should be large enough for a foreseeable future. Signed-off-by: NWei Huang <wei@redhat.com> (cherry picked from commit c13de016)
-
由 Eric Blake 提交于
On IRC, Hydrar pointed a problem where 'virsh edit' failed on his domain created through an ISCSI pool managed by virt-manager, all because the XML included a block device with colons in the name. * docs/schemas/basictypes.rng (absFilePath): Add colon as safe. * tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.xml: New file. * tests/qemuxml2argvdata/qemuxml2argv-disk-iscsi.args: Likewise. * tests/qemuxml2argvtest.c (mymain): Test it. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit dfc70875)
-
由 Jiri Denemark 提交于
Because of the microcode update to Haswell/Broadwell CPUs, existing domains using these CPUs may fail to start even though they used to run just fine. To help users solve this issue we try to suggest switching to -noTSX variant of the CPU model: virsh # start cd error: Failed to start domain cd error: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm, hle; try using 'Haswell-noTSX' CPU model Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 53c8062f)
-
由 Amy Fong 提交于
In some circumstances where the build tree differs from the source, libvirt's compile will try to create the symlink for cpu_map.xml before creating the directory $(abs_builddir)/cpu: 'src/cpu/cpu_map.xml': No such file or directory' Do not create the symlink, it is no longer needed after commit e562e82f Load CPU map from builddir when run uninstalled Signed-off-by: NAmy Fong <amy.fong@windriver.com> Signed-off-by: NJán Tomko <jtomko@redhat.com> (cherry picked from commit 237ffd1b)
-
由 Guido Günther 提交于
When using QEMU's 9pfs the target "dir" element is not necessarily an absolute path but merely an arbitrary identifier. So validation in that case currently fails with the misleading $ virt-xml-validate /tmp/test.xml Relax-NG validity error : Extra element devices in interleave /tmp/test.xml:24: element devices: Relax-NG validity error : Element domain failed to validate content /tmp/test.xml fails to validate (cherry picked from commit db1edae8)
-