- 22 9月, 2016 16 次提交
-
-
由 Jiri Denemark 提交于
The reworked API is now called virCPUUpdate and it should change the provided CPU definition into a one which can be consumed by the QEMU command line builder: - host-passthrough remains unchanged - host-model is turned into custom CPU with a model and features copied from host - custom CPU with minimum match is converted similarly to host-model - optional features are updated according to host's CPU Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The domain capabilities XML is capable of showing whether each guest CPU mode is supported or not with a possibility to provide additional details. This patch enhances host-model capability to advertise the exact CPU model which will be used as a host-model: <cpu> ... <mode name='host-model' supported='yes'> <model fallback='allow'>Broadwell</model> <vendor>Intel</vendor> <feature policy='disable' name='aes'/> <feature policy='require' name='vmx'/> </mode> ... </cpu> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
In case a hypervisor is able to tell us a list of supported CPU models and whether each CPU models can be used on the current host, we can propagate this to domain capabilities. This is a better alternative to calling virConnectCompareCPU for each supported CPU model. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Listing all CPU models supported by QEMU in domain capabilities makes little sense when libvirt will refuse any model it doesn't know about. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
To have a single place where we decide whether a guest can run natively on a host. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemu_command.c should deal with translating our domain definition into a QEMU command line and nothing else. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuCaps->arch should match the guest architecture from domain XML. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Our internal APIs mostly use virArch rather than strings. Switching cpuGetModels to virArch will save us from unnecessary conversions in the future. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Chen Hanxiao 提交于
We have a few of senarios that libvirtd would invoke qemuProcessStop and leave a "shutting down" in /var/log/libvirt/qemu/$DOMAIN.log. The shutoff reason showing in debug log is also very important for us to know why VM shutting down in domain log, as we seldom enable debug log of libvirtd. Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
- 21 9月, 2016 5 次提交
-
-
由 Peter Krempa 提交于
Calling virDomainGetEmulatorPinInfo on a live VM with automatic NUMA pinning and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning data in some cases which is bogus. Use the autoCpuset property only when called on a live definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1365779
-
由 Peter Krempa 提交于
Calling virDomainGetVcpuPinInfo on a live VM with automatic NUMA pinning and VIR_DOMAIN_AFFECT_CONFIG would return the automatic pinning data in some cases which is bogus. Use the autoCpuset property only when called on a live definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1365779
-
由 Peter Krempa 提交于
Sometimes adding a separate variable to access vm->privateData is not necessary. Add a macro that will do the typecasting rather than having to add a temp variable to force the compiler to typecast it.
-
由 Jiri Denemark 提交于
Old libvirt represents <graphics type='spice'> <listen type='none'/> </graphics> as <graphics type='spice' autoport='no'/> In this mode, QEMU doesn't listen for SPICE connection anywhere and clients have to use virDomainOpenGraphics* APIs to attach to the domain. That is, the client has to run on the same host where the domains runs and it's impossible to tell the client to reconnect to the destination QEMU during migration (unless there is some kind of proxy on the host). While current libvirt correctly ignores such graphics devices when creating graphics migration cookie, old libvirt just sends <graphics type='spice' port='0' listen='0.0.0.0' tlsPort='-1'/> in the cookie. After seeing this cookie, we happily would call client_migrate_info QMP command and wait for SPICE_MIGRATE_COMPLETED event, which is quite pointless since the doesn't know where to connecti anyway. We should just ignore such cookies. https://bugzilla.redhat.com/show_bug.cgi?id=1376083Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Checking if a domain's definition or if it is active before we got a job is pointless since the domain might have changed in the meantime. Luckily libvirtd didn't crash when the API tried to talk to an inactive domain: debug : qemuDomainObjBeginJobInternal:2914 : Started job: modify (async=none vm=0x7f8f340140c0 name=ble) debug : qemuDomainObjEnterMonitorInternal:3137 : Entering monitor (mon=(nil) vm=0x7f8f340140c0 name=ble) warning : virObjectLock:319 : Object (nil) ((unknown)) is not a virObjectLockable instance debug : qemuMonitorOpenGraphics:3505 : protocol=spice fd=27 fdname=graphicsfd skipauth=1 error : qemuMonitorOpenGraphics:3508 : invalid argument: monitor must not be NULL debug : qemuDomainObjExitMonitorInternal:3160 : Exited monitor (mon=(nil) vm=0x7f8f340140c0 name=ble) debug : qemuDomainObjEndJob:3068 : Stopping job: modify (async=none vm=0x7f8f340140c0 name=ble) Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 20 9月, 2016 13 次提交
-
-
由 Nikolay Shirokovskiy 提交于
We can receive NULL as sync reply in two situations. First is garbage sync reply and this situation is handled by resending sync message. Second is different cases of rebooting guest, destroing domain etc and we can give more meaningful error message. Actually we have this error message in qemuAgentCommand already which checks for the same sitatuion. AFAIK case with mon->running is just to be safe on adding some future(?) cases of returning NULL reply.
-
由 Nikolay Shirokovskiy 提交于
We can easily handle receiving garbage on sync. We don't have to make client deal with this situation. We just need to resend sync command but this time garbage is not be possible.
-
由 Nikolay Shirokovskiy 提交于
When we wait for sync reply we can receive delayed reply to syncs or commands that were sent erlier. We can safely skip them until we receive sync reply with correct id. There is no much sense report this situation to client. Actually with a bit of "luck" if we involve client into this the play can go on forever: send sync 0, receive sync reply -1, send sync 1, receive reply 0 ...
-
由 Nikolay Shirokovskiy 提交于
After sync is sent we can receive garbare and this is not error. Consider next regular case: 1. libvirtd sends sync 2. qga sends partial sync reply and die 3. libvirtd sends sync 4. qga sends sync reply 5. libvirtd receives garbage (half of first reply and second reply together) We should handle this situation as it is recoverable. Next sync can succeed. Let's report reply is NULL, it will be converted to the VIR_ERR_AGENT_UNSYNCED which signals client to retry.
-
由 Nikolay Shirokovskiy 提交于
Errors in qemuAgentIOProcessLine stop agent IO processing just like any regular IO error, however some of current errors that this functions spawns are false positives. Consider next case for example: 1. send sync (unsynced state) 2. receive sync reply (sync established) 3. command send, but timeout occured (unsynced state) 4. receive command reply Last IO triggers error because current code ignores only delayed syncs when unsynced We should not treat any delayed reply as error in unsynced state. Until client and qga are not in sync delayed reply to any command is possible. msg == NULL is the exact criterion that we are not in sync.
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
There will be more backends in the future so let's not complicate it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Put it into qemuDomainPrepareShmemChardev() so it can be used later. Also don't fill in the path unless the server option is enabled. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Always format id first so that we don't need to do that twice in different code paths. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Some checks will need to be performed for newer device types as well, so let's not duplicate them. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This will make sense after adding support for newer device types. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
It isn't used anywhere else. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Chen Hanxiao 提交于
s/unitl/until Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
- 19 9月, 2016 3 次提交
-
-
由 Michal Privoznik 提交于
Now that we have two same implementations for getting path for huge pages backed guest memory, lets merge them into one function. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When trying to migrate a huge page enabled guest, I've noticed the following crash. Apparently, if no specific hugepages are requested: <memoryBacking> <hugepages/> </memoryBacking> and there are no hugepages configured on the destination, we try to dereference a NULL pointer. Program received signal SIGSEGV, Segmentation fault. 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 1447 if (virAsprintf(&ret, "%s/libvirt/qemu", hugepage->mnt_dir) < 0) (gdb) bt #0 0x00007fcc907fb20e in qemuGetHugepagePath (hugepage=0x0) at qemu/qemu_conf.c:1447 #1 0x00007fcc907fb2f5 in qemuGetDefaultHugepath (hugetlbfs=0x0, nhugetlbfs=0) at qemu/qemu_conf.c:1466 #2 0x00007fcc907b4afa in qemuBuildMemoryBackendStr (size=4194304, pagesize=0, guestNode=0, userNodeset=0x0, autoNodeset=0x0, def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, backendType=0x7fcc95087228, backendProps=0x7fcc95087218, force=false) at qemu/qemu_command.c:3297 #3 0x00007fcc907b4f91 in qemuBuildMemoryCellBackendStr (def=0x7fcc70019070, qemuCaps=0x7fcc70004000, cfg=0x7fcc5c011800, cell=0, auto_nodeset=0x0, backendStr=0x7fcc70020360) at qemu/qemu_command.c:3413 #4 0x00007fcc907c0406 in qemuBuildNumaArgStr (cfg=0x7fcc5c011800, def=0x7fcc70019070, cmd=0x7fcc700040c0, qemuCaps=0x7fcc70004000, auto_nodeset=0x0) at qemu/qemu_command.c:7470 #5 0x00007fcc907c5fdf in qemuBuildCommandLine (driver=0x7fcc5c07b8a0, logManager=0x7fcc70003c00, def=0x7fcc70019070, monitor_chr=0x7fcc70004bb0, monitor_json=true, qemuCaps=0x7fcc70004000, migrateURI=0x7fcc700199c0 "defer", snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START, standalone=false, enableFips=false, nodeset=0x0, nnicindexes=0x7fcc95087498, nicindexes=0x7fcc950874a0, domainLibDir=0x7fcc700047c0 "/var/lib/libvirt/qemu/domain-1-fedora") at qemu/qemu_command.c:9547 Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Chen Hanxiao 提交于
Both qemu monitor and agent print the same log on HUANGUP event, which would be confusing when reading libvirtd log. This patch will give a different log message to them. Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 9月, 2016 1 次提交
-
-
由 Laszlo Ersek 提交于
Most of QEMU's PCI display device models, such as: libvirt video/model/@type QEMU -device ------------------------- ------------ cirrus cirrus-vga vga VGA qxl qxl-vga virtio virtio-vga come with a linear framebuffer (sometimes called "VGA compatibility framebuffer"). This linear framebuffer lives in one of the PCI device's MMIO BARs, and allows guest code (primarily: firmware drivers, and non-accelerated OS drivers) to display graphics with direct memory access. Due to architectural reasons on aarch64/KVM hosts, this kind of framebuffer doesn't / can't work in qemu-system-(arm|aarch64) -M virt machines. Cache coherency issues guarantee a corrupted / unusable display. The problem has been researched by several people, including kvm-arm maintainers, and it's been decided that the best way (practically the only way) to have boot time graphics for such guests is to consolidate on QEMU's "virtio-gpu-pci" device. >From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt supports <devices> <video> <model type='virtio'/> </video> </devices> but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga" device model. (See the qemuBuildDeviceVideoStr() function and the "qemuDeviceVideo" enum impl.) According to the above, this is not right for the "virt" machine type; the qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga" device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure virtio device without a compatibility framebuffer, is available, and works fine. (The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware for "virt" -- supports "virtio-gpu-pci", as of upstream commit 3ef3209d3028. See <https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.) Override the default mapping of "virtio", from "virtio-vga" to "virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true. Cc: Andrea Bolognani <abologna@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901Signed-off-by: NLaszlo Ersek <lersek@redhat.com> Acked-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 14 9月, 2016 2 次提交
-
-
由 Peter Krempa 提交于
Use the state information (online, hotpluggable) provided by the monitor code rather than trying to infer it. This fixes an issue where on architectures that require hotplug of multiple threads at once the sub-cores would get updated as offline on daemon restart thus creating an invalid configuration. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1375783
-
由 Peter Krempa 提交于
Return whether a vcpu entry is hotpluggable or online so that upper layers don't have to infer the information from other data. Advantage is that this code can be tested by unit tests.
-