[pull] master from libvirt:master #2931
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently translated at 4.3% (457 of 10442 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/ka/ Co-authored-by: Weblate <[email protected]> Signed-off-by: Weblate <[email protected]>
Commit 23c4794 added parsing of serial ports connected to vspc, but the VM can also have a network serial port with an empty filename or no filename at all. Parse these the same way, as a <serial type='null'>. Resolves: https://issues.redhat.com/browse/RHEL-32182 Signed-off-by: Martin Kletzander <[email protected]> Reviewed-by: Ján Tomko <[email protected]>
Currently translated at 76.3% (7982 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 76.1% (7962 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 75.9% (7942 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 75.5% (7902 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 75.3% (7882 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 75.2% (7862 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Translated using Weblate (Swedish) Currently translated at 74.8% (7822 of 10454 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/sv/ Co-authored-by: Göran Uddeborg <[email protected]> Signed-off-by: Göran Uddeborg <[email protected]>
As a part of parsing XML, virFirewallParseXML() calls
virXMLNodeContentString() and then passes the return value
further. But virXMLNodeContentString() is documented so that it's
the caller's responsibility to free the returned string, which
virFirewallParseXML() never does. This leads to a memory leak:
14,300 bytes in 220 blocks are definitely lost in loss record 1,879 of 1,891
at 0x4841858: malloc (vg_replace_malloc.c:442)
by 0x5491E3C: xmlBufCreateSize (in /usr/lib64/libxml2.so.2.12.6)
by 0x54C2401: xmlNodeGetContent (in /usr/lib64/libxml2.so.2.12.6)
by 0x49F7791: virXMLNodeContentString (virxml.c:354)
by 0x4979F25: virFirewallParseXML (virfirewall.c:1134)
by 0x4ABEB1E: virNetworkLoadState (virnetworkobj.c:938)
by 0x4ABF35C: virNetworkObjLoadAllState (virnetworkobj.c:1072)
by 0x4E9A25E: networkStateInitialize (bridge_driver.c:624)
by 0x4CB1FA6: virStateInitialize (libvirt.c:665)
by 0x15A6C6: daemonRunStateInit (remote_daemon.c:611)
by 0x49E69F0: virThreadHelper (virthread.c:256)
by 0x532B428: start_thread (in /lib64/libc.so.6)
Signed-off-by: Michal Privoznik <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
…kObjSetFwRemoval() The virNetworkObjSetFwRemoval() function is called at least two times when there's a network running and network driver initializes: 1) when loading state XMLs: #0 virNetworkObjSetFwRemoval (obj=0x7fffd4028250, fwRemoval=0x7fffd4020ad0) at ../src/conf/virnetworkobj.c:258 #1 0x00007ffff7a69c68 in virNetworkLoadState (...) at ../src/conf/virnetworkobj.c:952 #2 0x00007ffff7a6a35d in virNetworkObjLoadAllState (...) at ../src/conf/virnetworkobj.c:1072 #3 0x00007ffff7f9625f in networkStateInitialize (...) at ../src/network/bridge_driver.c:624 2) when firewall rules are being reloaded: #0 virNetworkObjSetFwRemoval (obj=0x7fffd4028250, fwRemoval=0x7fffd402e5b0) at ../src/conf/virnetworkobj.c:258 #1 0x00007ffff7f997b4 in networkReloadFirewallRulesHelper (obj=0x7fffd4028250, opaque=0x0) at ../src/network/bridge_driver.c:1703 #2 0x00007ffff7a6b09b in virNetworkObjListForEachHelper (payload=0x7fffd4028250, ...) at ../src/conf/virnetworkobj.c:1414 #3 0x00007ffff79287b6 in virHashForEachSafe (...) at ../src/util/virhash.c:387 #4 0x00007ffff7a6b119 in virNetworkObjListForEach (...) at ../src/conf/virnetworkobj.c:1441 #5 0x00007ffff7f99978 in networkReloadFirewallRules (...) at ../src/network/bridge_driver.c:1742 #6 0x00007ffff7f962f2 in networkStateInitialize (...) at ../src/network/bridge_driver.c:645 Since virNetworkObjSetFwRemoval() does not free the object stored in the first call, the second call just overwrites the stored pointer leading to a memory leak: 5,530 (48 direct, 5,482 indirect) bytes in 1 blocks are definitely lost in loss record 1,863 of 1,880 at 0x4848C43: calloc (vg_replace_malloc.c:1595) by 0x4F1E979: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.7800.6) by 0x4976E32: virFirewallNew (virfirewall.c:118) by 0x4979BA9: virFirewallParseXML (virfirewall.c:1071) by 0x4ABEB1E: virNetworkLoadState (virnetworkobj.c:938) by 0x4ABF35C: virNetworkObjLoadAllState (virnetworkobj.c:1072) by 0x4E9A25E: networkStateInitialize (bridge_driver.c:624) by 0x4CB1FA6: virStateInitialize (libvirt.c:665) by 0x15A6C6: daemonRunStateInit (remote_daemon.c:611) by 0x49E69F0: virThreadHelper (virthread.c:256) by 0x532B428: start_thread (in /lib64/libc.so.6) by 0x5397373: clone (in /lib64/libc.so.6) Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
Refactor the storage type fixup into a reusable method. Reviewed-by: Marc Hartmayer <[email protected]> Signed-off-by: Boris Fiuczynski <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
In newer DASD driver versions the ID_TYPE tag is supported. This tag is missing after a system reboot but when the ccw device is set offline and online the tag is included. To fix this version independently we need to check if devices detected as type disk is actually a DASD to maintain the node object consistency and not end up with multiple node objects for DASDs. Resolves: https://issues.redhat.com/browse/RHEL-39497 Reviewed-by: Marc Hartmayer <[email protected]> Signed-off-by: Boris Fiuczynski <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Prevent the creation of a new DASD node object when the device does not exist. Resolves: https://issues.redhat.com/browse/RHEL-39497 Reviewed-by: Marc Hartmayer <[email protected]> Signed-off-by: Boris Fiuczynski <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Instead of fencing offline ccw devices add the state to the ccw capability. Resolves: https://issues.redhat.com/browse/RHEL-39497 Signed-off-by: Boris Fiuczynski <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…->disk' Similarly to other blockjob handlers, if there's no disk associated with the blockjob the handler needs to behave correctly. This is needed as the disk might have been de-associated on unplug or other operations. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…kjob data Clear the 'disk' member of 'blockjob' as we're freeing the disk object at this point. While this should not normally happen it was observed when other bug allowed the VM to be cleared while other threads didn't yet finish. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Document why this function exists and meaning of return values. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
… the VM 'qemuDomainObjStopWorker()' which is meant to dispose of the event loop thread for the monitor unlocks the VM object while disposing the thread to prevent possible deadlocks with events waiting on the monitor thread. Unfortunately 'qemuDomainObjStopWorker()' is called *before* the VM is marked as inactive by clearing 'vm->def->id', but at the same time it's no longer marked as 'beingDestroyed' when we're inside 'qemuProcessStop()'. If 'vm' would be kept locked this wouldn't be a problem. Same way it's not a problem for anything that uses non-ASYNC VM jobs, or when the monitor is accessed in an async job, as the 'destroy' job interlocks with those. It is a problem for code inside an async job which uses 'qemuDomainObjWait()' though. The API contract of qemuDomainObjWait() ensures the caller that the VM on successful return from it, but in this specific reason it's not the case, as both 'beingDestroyed' is already false, and 'vm->def->id' is not yet cleared. To fix the issue move the 'qemuDomainObjStopWorker()' call *after* clearing 'vm->def->id' and also add a note stating what the function is doing. Fixes: 860a999 Closes: https://gitlab.com/libvirt/libvirt/-/issues/640 Reported-by: luzhipeng <[email protected]> Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
… of the ID There are few function calls done while cleaning up a stopped VM which do require the old VM id, to e.g. clean up paths containing the 'short' domain name in the path. Anything else, which doesn't strictly require it can be moved after clearing the 'id' in order to decrease likelyhood of potential bugs. This patch moves all the code which does not require the 'id' (except for the log entry and closing the monitor socket) after the statement clearing the id and adds a comment explaining that anything in the section must not unlock the VM object. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…M id is reset Prevent the possibility that a VM could be considered as alive while inside qemuProcessStop. A recently fixed bug which unlocked the domain object while inside qemuProcessStop showed that there's possibility to confuse the state of the VM to be considered active while 'qemuProcessStop' is processing shutdown of the VM. Ensure that this doesn't happen by clearing the 'beingDestroyed' flag only after the VM id is cleared. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
The helper checks whether VM is active including the internal qemu state. This helper will become useful in situations when an async job is in use as VIR_JOB_DESTROY can run along async jobs thus both checks are necessary. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Similarly to the one change in commit 4d1a1fd we should be checking that the VM is not being yet destroyed if we've invoked qemuDomainObjWait(). Use the new helper qemuDomainObjIsActive(). Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
The function is a pointless wrapper on top of qemuMigrationDstWaitForCompletion. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…ob data 'qemuProcessStop()' clears the 'current' job data. While the code under the 'error' label in 'qemuMigrationSrcRun()' does check that the VM is active before accessing the job, it also invokes multiple helper functions to clean up the migration including 'qemuMigrationSrcNBDCopyCancel()' which calls 'qemuDomainObjWait()' invalidating the result of the liveness check as it unlocks the VM. Duplicate the liveness check and explain why. The rest of the code e.g. accessing the monitor is safe as 'qemuDomainEnterMonitorAsync()' performs a liveness check. The cleanup path just ignores the return values of those functions. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
…rror paths When a VM terminates itself while it's being migrated in running state libvirt would report wrong error: error: cannot get locked memory limit of process 2502057: No such file or directory rather than the proper error: error: operation failed: domain is not running Remember the error on error paths in qemuMigrationSrcConfirmPhase and qemuMigrationSrcPerformPhase. Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
While working on qemuMonitorJSONGetSEVMeasurement() and qemuMonitorJSONGetSEVInfo() I've noticed that if these functions fail, they do so without appropriate error set. Fill in error reporting. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
Some parts of SEV are to be shared with SEV SNP. In order to reuse XML parsing / formatting code cleanly, let's move those common bits into a new struct (virDomainSEVCommonDef) and adjust rest of the code. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
To avoid convolution of switch() inside of virDomainSecDefFormat() even more (as new sectypes are added), move formatting into a separate function. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
The sectype member of _virDomainSecDef struct is already declared as of virDomainLaunchSecurity type. There's no need to typecast it to the very same type when passing it to switch(). Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
In a few instances there is a plain if() check for _virDomainSecDef::sectype. While this works perfectly for now, soon there'll be another type and we can utilize compiler to identify all the places that need adaptation. Switch those if() statements to switch(). Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
In QEMU commit v9.0.0-1155-g59d3740cb4 the return type of 'query-sev' monitor command changed to accommodate SEV-SNP. Even though we currently support launching plain SNP guests, this will soon change. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
This capability tracks sev-snp-guest object availability. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
SEV-SNP is an enhancement of SEV/SEV-ES and thus it shares some fields with it. Nevertheless, on XML level, it's yet another type of <launchSecurity/>. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]>
Currently translated at 48.6% (5110 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/en_GB/ Signed-off-by: Andi Chandler <[email protected]>
Check for the last multipart message right as the first thing. The presumption probably was that the last message might still contain a payload we want to parse. However that cannot be true since that would have to be a type RTM_NEWNEIGH. This was not caught because older kernels were note sending NLMSG_DONE and probably relied on the fact that the parsing just stops after all the messages are walked through, which the NLMSG_OK macro successfully did. Resolves: https://issues.redhat.com/browse/RHEL-52449 Resolves: https://bugzilla.redhat.com/2302245 Fixes: a176d67 Signed-off-by: Martin Kletzander <[email protected]> Reviewed-by: Laine Stump <[email protected]>
Currently translated at 95.8% (10072 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/zh_CN/ Signed-off-by: jianqing yan <[email protected]>
There is a family of convenient macros: NULLSTR, NULLSTR_EMPTY,
NULLSTR_STAR, NULLSTR_MINUS which hides ternary operator.
Generated using the following spatch (and its obvious variants):
@@
expression s;
@@
<+...
- s ? s : "<null>"
+ NULLSTR(s)
...+>
Signed-off-by: Michal Privoznik <[email protected]>
Reviewed-by: Peter Krempa <[email protected]>
All calls to vshTableRowAppend() inside of cmdList() share couple of same arguments: domain ID, domain name and domain state. While the first one is stored in a variable and then passed to all vshTableRowAppend() calls, the others are passed as a function call. Switch the latter to variables too. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
Instead of having many if-else statements, each with its own vshTableRowAppend() call, we can use a simple trick - have an array of string pointers, set array members in the if bodies and then call vshTableRowAppend() once. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
This function validates whether parsed limits are within range as defined by 'tc' sources (since we use tc to set QoS; or OVS which then uses tc too). The 'tc' program stores speeds in 64bit integers (unit is bytes per second) and sizes in uints (unit is bytes). We use different units: kilobytes per second and kibibytes and therefore we can parse values larger than 'tc' can handle and thus need a function to check if values still fit. Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
Since we use 'tc' to set QoS, or we instruct OVS which then uses 'tc', we have to make sure values are within range acceptable to 'tc'. Resolves: https://issues.redhat.com/browse/RHEL-45200 Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
In its commit v9.0.0-rc0~1^2 QEMU started to read /proc/sys/vm/max_map_count file to set up coroutine limits better (something about VMAs, mmap(), see the commit for more info). Allow the file in apparmor profile. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/660 Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
Currently translated at 95.8% (10072 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/zh_CN/ Signed-off-by: jianqing yan <[email protected]>
Some code paths, such as if hotplug of an empty cdrom fails can cause that 'qemuBlockStorageSourceChainDetach' will be called with 'NULL' @DaTa as there is no backend for the disk. The above case became possible once we allowed hotplug of cdroms and subsequently fixed the case when users would hotplug an empty cdrom which ultimately caused the possibility of having no backend in the hotplug code path which was not possible before (see 'Fixes:' below and also the commit linked from there). Make 'qemuBlockStorageSourceChainDetach' tolerate NULL @DaTa by simply returning early. Fixes: 894c6c5 Resolves: https://issues.redhat.com/browse/RHEL-54550 Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Martin Kletzander <[email protected]>
Attempting to start qemu with or hotplug an empty 'usb-storage' based
disk results in the following error:
qemu-system-x86_64: -device {"driver":"usb-storage","bus":"usb.0","port":"2","id":"usb-disk1","removable":true}: drive property not set
Reject such config at validation step and adjust tests.
Signed-off-by: Peter Krempa <[email protected]>
Reviewed-by: Martin Kletzander <[email protected]>
Currently translated at 48.6% (5116 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/en_GB/ Signed-off-by: Andi Chandler <[email protected]>
Up until now, we've assumed that all x86 machines have a PS/2 controller built-in. This assumption was correct until QEMU v4.2 introduced a new x86-based machine type - microvm. Due to this assumption, a pair of unnecessary PS/2 inputs are implicitly added to all microvm domains. This patch fixes that by whitelisting machine types which are known to include the i8042 PS/2 controller. Signed-off-by: Kamil Szczęk <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
This capability tells us whether given QEMU binary supports the '-machine xxx,i8042=on/off' toggle used to enable/disable PS/2 controller emulation. A few facts: - This option was introduced in QEMU 7.0 and defaults to 'on' - QEMU versions before 7.0 enabled i8042 controller emulation implicitly - This option (and i8042 controller emulation itself) is only supported by descendants of the generic PC machine type (e.g. i440fx, q35, etc.) Signed-off-by: Kamil Szczęk <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
This introduces a new 'ps2' feature which, when disabled, results in no implicit PS/2 bus input devices being automatically added to the domain and addition of the 'i8042=off' machine option to the QEMU command-line. A notable side effect of disabling the i8042 controller in QEMU is that the vmport device won't be created. For this reason we will not allow setting the vmport feature if the ps2 feature is explicitly disabled. Signed-off-by: Kamil Szczęk <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Introduce tests to verify that the 'ps2' feature is correctly parsed when given either 'dirty' XML from a user or 'clean' canonical XML, as produced by libvirt. This also tests the transformation from libvirt's internal state to the aforementioned canonical form and to a QEMU command line. As a bonus, we also test some known bad configurations: - When user explicitly adds ps2 bus inputs, but also explicitly disables the 'ps2' feature. - When user explicitly enables the 'vmport' feature, but also explicitly disables the 'ps2' feature. This is not supported by QEMU and will result in vmport device not being created without emitting any warning or error. Signed-off-by: Kamil Szczęk <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
Signed-off-by: Kamil Szczęk <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
The aim is to move parts of vir_event_thread_finalize() that MAY block into a separate function, so that unrefing the a virEventThread no longer blocks (or require releasing and subsequent re-acquiring of a mutex). Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
Currently, qemuProcessStop() unlocks given domain object right in the middle of cleanup process. This is dangerous because there might be another thread which is executing virDomainObjListAdd(). And since the domain object is on the list of domain objects AND by the time qemuProcessStop() unlocks it the object is also marked as inactive, the other thread acquires the lock and switches vm->def pointer. The unlocking of domain object is needed though, to allow even processing thread finish its queue. Well, the processing can be done before any cleanup is attempted. Therefore, use freshly introduced virEventThreadStop() to join the event thread and drop lock/unlock from the middle of qemuProcessStop(). Now, there's a comment being removed that mentions qemuDomainObjStopWorker() and why it has to be called only after the domain is marked as dead. This comment is no longed applicable because call to qemuDomainObjStopWorker() is removed also. Moreover, priv->beingDestroyed is set to true before unlocking the domain object, thus any event processing callback is going to see the domain being destroyed and can chose to either exit early or finish processing event. Fixes: 3865410 Resolves: https://issues.redhat.com/browse/RHEL-49607 Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Peter Krempa <[email protected]>
Currently translated at 95.8% (10072 of 10508 strings) Translation: libvirt/libvirt Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/zh_CN/ Signed-off-by: jianqing yan <[email protected]>
qemu supports this enlightenment since version 7.10.
From the qemu commit:
The newly introduced enlightenment allow L0 (KVM) and L1 (Hyper-V)
hypervisors to collaborate to avoid unnecessary updates to L2
MSR-Bitmap upon vmexits.
Signed-off-by: Tim Wiederhake <[email protected]>
Reviewed-by: Martin Kletzander <[email protected]>
qemu supports this enlightenment since version 7.10.
From the qemu commit:
Hyper-V specification allows to pass parameters for certain hypercalls
using XMM registers ("XMM Fast Hypercall Input"). When the feature is
in use, it allows for faster hypercalls processing as KVM can avoid
reading guest's memory.
Signed-off-by: Tim Wiederhake <[email protected]>
Reviewed-by: Martin Kletzander <[email protected]>
From: Praveen K Paladugu <[email protected]> Move methods to connect domain interfaces to host bridges to hypervisor. This is to allow reuse between qemu and ch drivers. Signed-off-by: Praveen K Paladugu <[email protected]> Signed-off-by: Praveen K Paladugu <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
From: Praveen K Paladugu <[email protected]> enable VIR_DOMAIN_NET_TYPE_NETWORK network support for ch guests. Tested with following config: <interface type='network'> <source network="default" bridge='virbr0'/> <model type='virtio'/> <driver queues="1"/> </interface> Signed-off-by: Praveen K Paladugu <[email protected]> Signed-off-by: Praveen K Paladugu <[email protected]> Signed-off-by: Michal Privoznik <[email protected]> Reviewed-by: Michal Privoznik <[email protected]>
'bhyveConnectGetType' (which is called from 'virConnectGetType') returns 'BHYVE' as the type, but the code in 'remoteDispatchConnectOpen' responsible for selecting the sub-driver URIs in modular deployment checks for 'bhyve' and thus would not properly fill the URIs to the sub-daemons. Signed-off-by: aokblast <[email protected]> Signed-off-by: Peter Krempa <[email protected]> Reviewed-by: Pavel Hrdina <[email protected]>
|
Thank you for your interest in the libvirt project. Since this repository is a read-only mirror of the project's master We kindly request that contributors fork the project at https://gitlab.com/libvirt/libvirt/ push changes to the fork, and then open a new merge request at https://gitlab.com/libvirt/libvirt/-/merge_requests/new Thank you for your time and understanding. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )