- 04 10月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
This breaks vCPU hotplug, because when starting a domain, we create a copy of domain definition (which becomes live XML) and during the post parse callbacks we might adjust some tunings so that vCPU hotplug is possible. This reverts commit c0f90799.
-
- 30 9月, 2016 5 次提交
-
-
由 Peter Krempa 提交于
Certain operations may make the vcpu order information invalid. Since the order is primarily used to ensure migration compatibility and has basically no other user benefits, clear the order prior to certain operations and document that it may be cleared. All the operations that would clear the order can still be properly executed by defining a new domain configuration rather than using the helper APIs. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370357
-
由 Peter Krempa 提交于
virDomainDefSetVcpus was not designed to handle coldplug of vcpus now that we can set state of vcpus individually. Introduce qemuDomainSetVcpusConfig that properly handles state changes of vcpus when coldplugging so that invalid configurations are not created. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1375939
-
由 Peter Krempa 提交于
The current code that validates duplicate vcpu order would not work properly if the order would exceed def->maxvcpus. Limit the order to the interval described.
-
由 Peter Krempa 提交于
Allocate a one larger bitmap rather than shifting the indexes back to zero.
-
由 Peter Krempa 提交于
The bitmap indexes for the order duplicate check are shifted to 0 since vcpu order 0 is not allowed. The error message doesn't need such treating though. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1370360
-
- 29 9月, 2016 5 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1292984 Hold on to your hats, because this is gonna be wild. In bd3e16a3 I've tried to expose sanlock io_timeout. What I had not realized (because there is like no documentation for sanlock at all) was very unusual way their APIs work. Basically, what we do currently is: sanlock_add_lockspace_timeout(&ls, io_timeout); which adds a lockspace to sanlock daemon. One would expect that io_timeout sets the io_timeout for it. Nah! That's where you are completely off the tracks. It sets timeout for next lockspace you will probably add later. Therefore: sanlock_add_lockspace_timeout(&ls, io_timeout = 10); /* adds new lockspace with default io_timeout */ sanlock_add_lockspace_timeout(&ls, io_timeout = 20); /* adds new lockspace with io_timeout = 10 */ sanlock_add_lockspace_timeout(&ls, io_timeout = 40); /* adds new lockspace with io_timeout = 20 */ And so on. You get the picture. Fortunately, we don't allow setting io_timeout per domain or per domain disk. So we just need to set the default used in the very first step and hope for the best (as all the io_timeout-s used later will have the same value). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Currently, we are checking for sanlock_add_lockspace_timeout which is good for now. But in a subsequent patch we are going to use sanlock_write_lockspace (which sets an initial value for io timeout for sanlock). Now, there is no reason to check for both functions in sanlock library as the sanlock_write_lockspace was introduced in 2.7 release and the one we are currently checking for in the 2.5 release. Therefore it is safe to assume presence of sanlock_add_lockspace_timeout when sanlock_write_lockspace is detected. Moreover, the macro for conditional compilation is renamed to HAVE_SANLOCK_IO_TIMEOUT (as it now encapsulates two functions). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Global variables are bad, we should avoid using them. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Martin Kletzander 提交于
If this reminds you of a commit message from around a year ago, it's 41c2aa72 and yes, we're dealing with "the same thing" again. Or f309db1f and it's similar. There is a logic in place that if there is no real need for memory-backend-file, qemuBuildMemoryBackendStr() returns 0. However that wasn't the case with hugepage backing. The reason for that was that we abused the 'pagesize' variable for storing that information, but we should rather have a separate one that specifies whether we really need the new object for hugepage backing. And that variable should be set only if this particular NUMA cell needs special treatment WRT hugepages. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Roman Bogorodskiy 提交于
In commit 7f127ded cpuCompareXML was renamed to virCPUCompareXML, so change the bhyve driver to use the new function and thus fix the build.
-
- 28 9月, 2016 5 次提交
-
-
由 Jim Fehlig 提交于
Due to a copy and paste error, the scheduler 'cap' parameter was over-writing the 'weight' parameter when preparing the return parameters in libxlDomainGetSchedulerParametersFlags. As a result, the scheduler weight was never shown when getting schedinfo and setting the weight failed as well virsh schedinfo testvm Scheduler : credit cap : 0 virsh schedinfo testvm --cap 50 --weight 500 Scheduler : credit error: invalid scheduler option: weight The obvious fix is to assign the 'caps' parameter to the correct item in the parameter list. Reported-by: NVolo M. <vm@vovs.net>
-
由 Joao Martins 提交于
Add support for formating/parsing libxl channels. Syntax on xen libxl goes as following: channel=["connection=pty|socket,path=/path/to/socket,name=XXX",...] Signed-off-by: NJoao Martins <joao.m.martins@oracle.com> Acked-by: NJim Fehlig <jfehlig@suse.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Joao Martins 提交于
And allow libxl to handle channel element which creates a Xen console visible to the guest as a low-bandwitdh communication channel. If type is PTY we also fetch the tty after boot using libxl_channel_getinfo to fetch the tty path. On socket case, we autogenerate a path if not specified in the XML. Path autogenerated is slightly different from qemu driver: qemu stores also on "channels/target" but it creates then a directory per domain with each channel target name. libxl doesn't appear to have a clear definition of private files associated with each domain, so for simplicity we do it slightly different. On qemu each autogenerated channel goes like: channels/target/<domain-name>/<target name> Whereas for libxl: channels/target/<domain-name>-<target name> Should note that if path is not specified it won't persist, existing only on live XML, unless user had initially specified it. Since support for libxl channels only came on Xen >= 4.5 we therefore need to conditionally compile it with LIBXL_HAVE_DEVICE_CHANNEL. After this patch and having a qemu guest agent: $ cat domain.xml | grep -a1 channel | head -n 5 | tail -n 4 <channel type='unix'> <source mode='bind' path='/tmp/channel'/> <target type='xen' name='org.qemu.guest_agent.0'/> </channel> $ virsh create domain.xml $ echo '{"execute":"guest-network-get-interfaces"}' | socat stdio,ignoreeof unix-connect:/tmp/channel {"execute":"guest-network-get-interfaces"} {"return": [{"name": "lo", "ip-addresses": [{"ip-address-type": "ipv4", "ip-address": "127.0.0.1", "prefix": 8}, {"ip-address-type": "ipv6", "ip-address": "::1", "prefix": 128}], "hardware-address": "00:00:00:00:00:00"}, {"name": "eth0", "ip-addresses": [{"ip-address-type": "ipv4", "ip-address": "10.100.0.6", "prefix": 24}, {"ip-address-type": "ipv6", "ip-address": "fe80::216:3eff:fe40:88eb", "prefix": 64}], "hardware-address": "00:16:3e:40:88:eb"}, {"name": "sit0"}]} Signed-off-by: NJoao Martins <joao.m.martins@oracle.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Joao Martins 提交于
So far only guestfwd and virtio were supported. Add an additional for Xen as libxl channels create a Xen console visible to the guest. Signed-off-by: NJoao Martins <joao.m.martins@oracle.com> Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jiri Denemark 提交于
The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with caps == NULL, causing the following crash: Program received signal SIGSEGV, Segmentation fault. #0 0x00007ffff788775f in virQEMUCapsInitHostCPUModel (qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at src/qemu/qemu_capabilities.c:2969 #1 0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal (caps=caps@entry=0x0, binary=<optimized out>, libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0, runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295, qmpOnly=true) at src/qemu/qemu_capabilities.c:4039 #2 0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at tests/qemucapsprobe.c:73 Caused by v2.2.0-182-g68c70118. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 9月, 2016 4 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1368417 So far, when it comes to 'virsh update-device --config' of disks we are limiting ourselves for just the disk source update and just for CDROMs and floppies. This makes no sense. Especially if you look around and see that we already allow full update to graphics and net devices. So let's just take whatever XML user wants to have there and replace our internal definition with it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jim Fehlig 提交于
libxl events are delivered to libvirt via the libxlDomainEventHandler callback registered with libxl. Documenation in $xensrc/tools/libxl/libxl_event.h states that the callback "may occur on any thread in which the application calls libxl". This can result in deadlock since many of the libvirt callees of libxl hold a lock on the virDomainObj they are working on. When the callback is invoked, it attempts to find a virDomainObj corresponding to the domain ID provided by libxl. Searching the domain obj list results in locking each obj before checking if it is active, and its ID equals the requested ID. Deadlock is possible when attempting to lock an obj that is already locked further up the call stack. Indeed, Max Ustermann reported an instance of this deadlock https://www.redhat.com/archives/libvir-list/2015-November/msg00130.html Guido Rossmueller also recently stumbled across it https://www.redhat.com/archives/libvir-list/2016-September/msg00287.html Fix the deadlock by moving the lookup of virDomainObj to the libxlDomainShutdownThread. After this patch, libxl events are enqueued on the libvirt side and processed by dedicated thread, avoiding the described deadlock. Reported-by: NMax Ustermann <ustermann78@web.de> Reported-by: NGuido Rossmueller <Guido.Rossmueller@gdata.de>
-
由 Daniel P. Berrange 提交于
enum types are unsigned and the qemuGetCompressionProgram function can return -1 on error. It is therefore inappropriate to return an enum type. This fixes a build error where the internal 'ret' variable was used in a comparison with -1 ../../src/qemu/qemu_driver.c: In function 'qemuGetCompressionProgram': ../../src/qemu/qemu_driver.c:3280:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] ../../src/qemu/qemu_driver.c:3289:5: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] cc1: all warnings being treated as errors Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
- 26 9月, 2016 20 次提交
-
-
由 Michal Privoznik 提交于
When creating a copy of virDomainDef we save ourselves the trouble of writing deep-copy functions and just format and parse back domain/device XML. However, the XML we are parsing was already fully formatted - there is no reason to run post parse callbacks (which fill in blanks - there are none!). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is an internal flag that prevents our two entry points to XML parsing (virDomainDefParse and virDomainDeviceDefParse) from running post parse callbacks. This is expected to be used in cases when we already have full domain/device XML and we are just parsing it back (i.e. virDomainDefCopy or virDomainDeviceDefCopy) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like we did two commits ago, don't try to fetch capabilities for non-existing binary. Re-use the ones we have for running domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like we did two commits ago, don't try to fetch capabilities for non-existing binary. Re-use the ones we have for running domain. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We can't rely on def->emulator path. It may be provided by user as we give them opportunity to provide their own XML for migration. Therefore the path may point to just whatever binary (or even to a non-existent file). Moreover, this path is meant for destination, but the capabilities lookup is done on source. What we can do is to assume same capabilities for post parse callbacks as the running domain has. They will be used just to add some default models/controllers/devices/... anyway. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like virDomainDefPostParseCallback has gained new parseOpaque argument, we need to follow the logic with virDomainDeviceDefPostParse. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParseString. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParse and subsequently virDomainDefParseNode too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParseXML and subsequently virDomainDefPostParse too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Some callers might want to pass yet another pointer to opaque data to post parse callbacks. The driver generic one is not enough because two threads executing post parse callback might want to see different data (e.g. domain object pointer that domain def belongs to). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Chen Hanxiao 提交于
Remove unnessary translated message marker _() for the VIR_WARN messages. Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
由 Nitesh Konkar 提交于
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
-
由 John Ferlan 提交于
Based upon a patch from Chen Hanxiao <chenhanxiao@gmail.com>, rather than need to call virFindFileInPath twice, let's just save the path and pass it along with the compressed type. (NB: the second call would be in virExec as called from virCommandRunAsync which is called from qemuMigrationToFile using the argument 'compressor' which up to this point would be the string from the cfg file that isn't the fully qualified path). Since we now have the path, we can remove qemuCompressProgramName which would return NULL or the string representation of the compress type.
-
由 John Ferlan 提交于
There's only one caller and the code is duplicitous just converting the recently converted cfg image name back into it's string value in order to get/find the path to the image. A subsequent patch can return this path.
-
由 John Ferlan 提交于
Let's do some more code reuse - there are 3 other callers that care to check/get the compress program. Each of those though cares whether the requested cfg image is valid and exists. So, add a parameter to handle those cases. NB: We won't need to initialize the returned value in the case where the cfg image doesn't exist since the called program will handle that.
-
由 John Ferlan 提交于
Add a new parameter 'styleFormat' to be used when printing the warning message so that it's "clearer" what style of compression call caused the error. Add that style to both messages as a paremter. Also a VIR_WARN error message doesn't need to be translated (e.g. inside _()), so remove the need for the translation.
-
由 John Ferlan 提交于
There's only one caller now anyway... Besides it's just a shell for getting the compress type. Subsequent patches will return the path to the compression program.
-
由 John Ferlan 提交于
Split out the guts of getCompressionType to perform the same functionality in the new helper program with a subsequent patch goal to be reusable for other callers making similar checks/calls to ensure the compression type is valid and that the compression program cannot be found.
-
由 John Ferlan 提交于
Rather than calling getCompressionType from each of the callers, just call it from doCoreDump. A subsequent patch will be adjust the code even more.
-