- 22 9月, 2016 29 次提交
-
-
由 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 提交于
The ARM CPU driver wrongly reported host CPU model as "host", which made host-model to be just an alias for host-passthrough. Let's drop this insanity. 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 提交于
The function filters all CPU features through a given callback while copying CPU model related parts of a CPU definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function moves CPU model related parts from one CPU definition to another. It can be used to avoid unnecessary copies from a temporary CPU definitions which will be freed anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Useful for copying a CPU definition without model related parts (i.e., without model name, feature list, vendor). 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 提交于
cpuGetSubDriver already reports a useful error. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Some CPU drivers (such as arm) do not provide list of CPUs libvirt supports and just pass any CPU model from domain XML directly to QEMU. Such driver need to return models == NULL and success from cpuGetModels. 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 提交于
The patch adds <cpu> element to domain capabilities XML: <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'/> <mode name='custom' supported='yes'> <model>Broadwell</model> <model>Broadwell-noTSX</model> ... </mode> </cpu> Applications can use it to inspect what CPU configuration modes are supported for a specific combination of domain type, emulator binary, guest architecture and machine type. 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>
-
由 Jim Fehlig 提交于
By default, virt-manager (and likely other libvirt-based apps) sets the VIR_MIGRATE_PERSIST_DEST flag when invoking the migrate API, which fails in a Xen setup since the libxl driver does not support the flag. Persisting a domain is a trivial task in the grand scheme of migration, so be nice to libvirt apps and add support for VIR_MIGRATE_PERSIST_DEST in the libxl driver. Signed-off-by: NJim Fehlig <jfehlig@suse.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>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 21 9月, 2016 7 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1322717 During offline migration, no storage is copied. Nor disks, nor NVRAM file, nor anything. We use qemu for that and because domain is not running there's nobody to copy that for us. We should document this to avoid confusing users. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 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.
-
由 Peter Krempa 提交于
Return whether the live or persistent definition was returned. Sometimes it's necessary to base the decisions on this.
-
由 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 4 次提交
-
-
由 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.
-