- 03 5月, 2017 4 次提交
-
-
由 Michal Privoznik 提交于
While the code allows devices to already be there (by some miracle), we shouldn't try to create devices that don't belong to us. For instance, we shouldn't try to create /dev/shm/file because /dev/shm is a mount point that is preserved. Therefore if a file is created there from an outside (e.g. by mgmt application or some other daemon running on the system like vhostmd), it exists in the qemu namespace too as the mount point is the same. It's only /dev and /dev only that is different. The same reasoning applies to all other preserved mount points. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Michal Privoznik 提交于
Currently, all we need to do in qemuDomainCreateDeviceRecursive() is to take given @device, get all kinds of info on it (major & minor numbers, owner, seclabels) and create its copy at a temporary location @path (usually /var/run/libvirt/qemu/$domName.dev), if @device live under /dev. This is, however, very loose condition, as it also means /dev/shm/* is created too. Therefor, we will need to pass more arguments into the function for better decision making (e.g. list of mount points under /dev). Instead of adding more arguments to all the functions (not easily reachable because some functions are callback with strictly defined type), lets just turn this one 'const char *' into a 'struct *'. New "arguments" can be then added at no cost. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Michal Privoznik 提交于
When setting up mount namespace for a qemu domain the following steps are executed: 1) get list of mountpoints under /dev/ 2) move them to /var/run/libvirt/qemu/$domName.ext 3) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev 4) move the mountpoint of the new device tree to /dev 5) restore original mountpoints from step 2) Note the problem with this approach is that if some device in step 3) requires access to a mountpoint from step 2) it will fail as the mountpoint is not there anymore. For instance consider the following domain disk configuration: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/shm/vhostmd0'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </disk> In this case operation fails as we are unable to create vhostmd0 in the new device tree because after step 2) there is no /dev/shm anymore. Leave aside fact that we shouldn't try to create devices living in other mountpoints. That's a separate bug that will be addressed later. Currently, the order described above is rearranged to: 1) get list of mountpoints under /dev/ 2) start constructing new device tree under /var/run/libvirt/qemu/$domName.dev 3) move them to /var/run/libvirt/qemu/$domName.ext 4) move the mountpoint of the new device tree to /dev 5) restore original mountpoints from step 3) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCedric Bosdonnat <cbosdonnat@suse.com>
-
由 Jiri Denemark 提交于
While fixing a bug with incorrectly freed memory in commit v3.1.0-399-g5498aa29, I accidentally broke persistent migration of transient domains. Before adding qemuDomainDefCopy in the path, the code just took NULL from vm->newDef and used it as the persistent def, which resulted in no persistent XML being sent in the migration cookie. This scenario is perfectly valid and the destination correctly handles it by using the incoming live definition and storing it as the persistent one. After the mentioned commit libvirtd would just segfault in the described scenario. https://bugzilla.redhat.com/show_bug.cgi?id=1446205Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 02 5月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
When creating v3.2.0-77-g8be3ccd0 commit, I completely forgot that one migration capability is very special. It's the "events" capability which tells QEMU to report "MIGRATION" events. Since libvirt always wants the events, it is enabled in qemuConnectMonitor and the rest of the code should not touch it. https://bugzilla.redhat.com/show_bug.cgi?id=1439841 https://bugzilla.redhat.com/show_bug.cgi?id=1441165Messed-up-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 28 4月, 2017 13 次提交
-
-
由 Laine Stump 提交于
... with VIR_NET_GENERATED_MACV???_PREFIX, which is defined in util/virnetdevmacvlan.h. Since VIR_NET_GENERATED_PREFIX is used for plain tap devices, it is renamed to VIR_NET_GENERATED_TAP_PREFIX and moved to virnetdev.h
-
由 Laine Stump 提交于
Nothing that could happen during networkNotifyActualDevice() could justify unceremoniously killing the qemu process, but that's what we were doing. In particular, new code added in commit 85bcc022 (first appearred in libvirt-3.2.0) attempts to reattach tap devices to their assigned bridge devices when libvirtd restarts (to make it easier to recover from a restart of a libvirt network). But if the network has been stopped and *not* restarted, the bridge device won't exist and networkNotifyActualDevice() will fail. This patch changes networkNotifyActualDevice() and qemuProcessNotifyNets() to return void, so that qemuProcessReconnect() will soldier on regardless of what happens (any errors will still be logged though). Partially resolves: https://bugzilla.redhat.com/1442700
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438682Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
This is a USB3 controller and it's a better choice than piix3-uhci. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Pavel Hrdina 提交于
The new logic will set the piix3-uhci if available regardless of any architecture and it will be updated to better model based on architecture and device existence. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> Acked-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Peter Krempa 提交于
Since commit c5f61513 qemuDomainBlockInfo tries to update the "physical" storage size for all network storage and not only block devices. Since the storage driver APIs to do this are not implemented for certain storage types (RBD, iSCSI, ...) the code would fail to retrieve any data since the failure of qemuDomainStorageUpdatePhysical is fatal. Since it's desired to return data even if the total size can't be updated we need to ignore errors from that function and return plausible data. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442344
-
由 Peter Krempa 提交于
Rather than freeing the list before starting a new VM clear it after stopping the old instance when the data becomes invalid.
-
由 Peter Krempa 提交于
The alias would be leaked, since it's not freed on the vm stop path.
-
由 Peter Krempa 提交于
Since the private data structure is not freed upon stopping a VM, the usbaddrs pointer would be leaked: ==15388== 136 (16 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 1,019 ==15388== at 0x4C2CF55: calloc (vg_replace_malloc.c:711) ==15388== by 0x54BF64A: virAlloc (viralloc.c:144) ==15388== by 0x5547588: virDomainUSBAddressSetCreate (domain_addr.c:1608) ==15388== by 0x144D38A2: qemuDomainAssignUSBAddresses (qemu_domain_address.c:2458) ==15388== by 0x144D38A2: qemuDomainAssignAddresses (qemu_domain_address.c:2515) ==15388== by 0x144ED1E3: qemuProcessPrepareDomain (qemu_process.c:5398) ==15388== by 0x144F51FF: qemuProcessStart (qemu_process.c:5979) [...]
-
由 Peter Krempa 提交于
Clean the stale data after shutting down the VM. Otherwise the data would be leaked on next VM start. This happens due to the fact that the private data object is not freed on destroy of the VM.
-
由 Jiri Denemark 提交于
This patch maps /domain/cpu/cache element into -cpu parameters: - <cache mode='passthrough'/> is translated to host-cache-info=on - <cache level='3' mode='emulate'/> is transformed into l3-cache=on - <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off Any other <cache> element is forbidden. The tricky part is detecting whether QEMU supports the CPU properties. The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480, earlier QEMU releases enabled host-cache-info by default and had no way to disable it. If the property is present, it defaults to 'off' for any QEMU until at least 2.9.0. The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa. Earlier versions worked as if l3-cache=off was passed. For any QEMU until at least 2.9.0 l3-cache is 'off' by default. QEMU 2.9.0 was the first release which supports probing both properties by running device-list-properties with typename=host-x86_64-cpu. Older QEMU releases did not support device-list-properties command for CPU devices. Thus we can't really rely on probing them and we can just use query-cpu-model-expansion QMP command as a witness. Because the cache property probing is only reliable for QEMU >= 2.9.0 when both are already supported for quite a few releases, we let QEMU report an error if a specific cache mode is explicitly requested. The other mode (or both if a user requested CPU cache to be disabled) is explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case the QEMU defaults change. Any older QEMU already turns them off so not doing so explicitly does not make any harm. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 4月, 2017 9 次提交
-
-
由 Jiri Denemark 提交于
Not all async jobs are visible via virDomainGetJobStats (either they are too fast or getting the stats is not allowed during the job), but forcing all of them to advertise the operation is easier than hunting the jobs for which fetching statistics is allowed. And we won't need to think about this when we add support for getting stats for more jobs. https://bugzilla.redhat.com/show_bug.cgi?id=1441563Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Eric Farman 提交于
As with virtio-scsi, the "internal error" messages after preparing a vhost-scsi hostdev overwrites more meaningful error messages deeper in the callchain. Remove it too. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
-
由 Eric Farman 提交于
I tried to attach a SCSI LUN to two different guests, and forgot to specify "shareable" in the hostdev XML. Attaching the device to the second guest failed, but the message was not helpful in telling me what I was doing wrong: $ cat scsi_scratch_disk.xml <hostdev mode='subsystem' type='scsi'> <source> <adapter name='scsi_host3'/> <address bus='0' target='15' unit='1074151456'/> </source> </hostdev> $ virsh attach-device dasd_sles_d99c scsi_scratch_disk.xml Device attached successfully $ virsh attach-device dasd_fedora_0e1e scsi_scratch_disk.xml error: Failed to attach device from scsi_scratch_disk.xml error: internal error: Unable to prepare scsi hostdev: scsi_host3:0:15:1074151456 I eventually discovered my error, but thought it was weird that Libvirt doesn't provide something more helpful in this case. Looking over the code we had just gone through, I commented out the "internal error" message, and got something more useful: $ virsh attach-device dasd_fedora_0e1e scsi_scratch_disk.xml error: Failed to attach device from scsi_scratch_disk.xml error: Requested operation is not valid: SCSI device 3:0:15:1074151456 is already in use by other domain(s) as 'non-shareable' Looking over the error paths here, we seem to issue better messages deeper in the callchain so these "internal error" messages overwrite any of them. Remove them, so that the more detailed errors are seen. Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
-
由 Eric Farman 提交于
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
-
由 Nikolay Shirokovskiy 提交于
0feebab2 adds calling qemuBlockNodeNamesDetect for completed job on updating block jobs. This affects cancelling drive mirror logic as this function drops vm lock. Now we have to recheck all disks before the disk with the completed block job before going to wait for block job events. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Nikolay Shirokovskiy 提交于
Becase it can be called during migration out (namely on cancelling blockjobs). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainGetNumaParameters would return the automatic nodeset even for the persistent config if the domain was running. This is incorrect since the automatic nodeset will be re-queried upon starting the vm. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1445325
-
由 Jiri Denemark 提交于
While peer-to-peer migration enters the Confirm phase even if the Perform phase fails, the client which initiated a non-p2p migration will never call virDomainMigrateConfirm* API if the Perform phase failed. Thus we need to explicitly reset migration before reporting a failure from the Perform phase API. https://bugzilla.redhat.com/show_bug.cgi?id=1425003Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Migration with old QEMU which does not support query-migrate-parameters would fail because the QMP command is called unconditionally since the introduction of TLS migration. Previously it was only called if the user explicitly requested a feature which uses QEMU migration parameters. And even then the situation was not ideal, instead of reporting an unsupported feature we'd just complain about missing QMP command. Trivially no migration parameters are supported when query-migrate-parameters QMP command is missing. There's no need to report an error if it is missing, the callers will report better error if needed. https://bugzilla.redhat.com/show_bug.cgi?id=1441934Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 25 4月, 2017 1 次提交
-
-
由 ZhiPeng Lu 提交于
it should be a comparison of modes between new and old devices. So the argument of the second virDomainNetGetActualDirectMode should be newdev. Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
-
- 24 4月, 2017 1 次提交
-
-
由 Yuri Chornoivan 提交于
-
- 21 4月, 2017 2 次提交
-
-
由 Martin Kletzander 提交于
This patch makes use of the virNetDevSetCoalesce() function to make appropriate settings effective for devices that support them. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414627Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
We are currently parsing only rx/frames/max because that's the only value that makes sense for us. The tun device just added support for this one and the others are only supported by hardware devices which we don't need to worry about as the only way we'd pass those to the domain is using <hostdev/> or <interface type='hostdev'/>. And in those cases the guest can modify the settings itself. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 20 4月, 2017 4 次提交
-
-
由 Peter Krempa 提交于
In the vcpu hotplug code if exit from the monitor failed we would still attempt to save the status XML. When the daemon is terminated the monitor socket is closed. In such case, the written status XML would not contain the monitor path and thus be invalid. Avoid this issue by only saving status XML on success of the monitor command. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1439452
-
由 Peter Krempa 提交于
The function is used only in the hotplug module.
-
由 Pavel Hrdina 提交于
The history of USB controller for ppc64 guest is complex and goes back to libvirt 1.3.1 where the fun started. Prior Libvirt 1.3.1 if no model for USB controller was specified we've simply passed "-usb" on QEMU command line. Since Libvirt 1.3.1 there is a patch (8156493d) that fixes this issue by using "-device pci-ohci,..." but it breaks migration with older Libvirts which was agreed that's acceptable. However this patch didn't reflect this change in the domain XML and the model was still missing. Since Libvirt 2.2.0 there is a patch (f55eaccb) that fixes the issue with not setting the USB model into domain XML which we need to know about to not break the migration and since the default model was *pci-ohci* it was used as default in this patch as well. This patch tries to take all the previous changes into account and also change the default for newly defined domains that don't specify any model for USB controller. The VIR_DOMAIN_DEF_PARSE_ABI_UPDATE is set only if new domain is defined or new device is added into a domain which means that in all other cases we will use the old *pci-ohci* model instead of the better and not broken *nec-usb-xhci* model. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373184Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
So far there is probably no change that is allowed to be done by the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE flag that would break guest ABI but this may change in the future. This introduces new VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION which should be used only for ABI updates that are "safe" for persistent migration. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 19 4月, 2017 5 次提交
-
-
由 Jiri Denemark 提交于
With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
To keep freeing of host CPU data in one place. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-