- 22 9月, 2016 15 次提交
-
-
由 Jiri Denemark 提交于
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 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 9 次提交
-
-
由 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>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 20 9月, 2016 16 次提交
-
-
由 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 提交于
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>
-
由 Andrea Bolognani 提交于
Commit 839a0608 tied the lifecycle of virtlogd more closely to that of libvirtd. Unfortunately, while starting virtlogd when libvirtd is started is definitely a good idea, restarting virtlogd or shutting it down at any time outside of system poweroff is not. Revert part of that commit by removing the PartOf= lines, meaning that only startup requests will be propagated from libvirtd to virtlogd. Resolves: https://bugzilla.redhat.com/1372576
-
由 Erik Skultety 提交于
Make use of the new recently introduced alias handling for virt-admin srv-* commands. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Change the logic in a way, so that VSH_CMD_FLAG_ALIAS behaves similarly to how VSH_OT_ALIAS for command options, i.e. there is no need for code duplication for the alias and the aliased command structures. Along with that change, switch any existing VSH_CMD_FLAG_ALIAS occurrences to this new format. Also, since this patch introduces a new command structure element, adjust the virsh-self-test test to make sure we won't ever miss to specify the '.alias' member for an aliased command because doing that would lead to an internal error. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-