On 03/17/2015 05:14 PM, Michal Privoznik wrote:
On 13.03.2015 16:52, Maxim Nestratov wrote:
network adapter is used
---
src/parallels/parallels_sdk.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/parallels/parallels_sdk.c b/src/parallels/parallels_sdk.c
index a0a2ba0..4c90a18 100644
--- a/src/parallels/parallels_sdk.c
+++ b/src/parallels/parallels_sdk.c
@@ -2246,7 +2246,8 @@ static int prlsdkCheckSerialUnsupportedParams(virDomainChrDefPtr chr)
static int prlsdkCheckNetUnsupportedParams(virDomainNetDefPtr net)
{
- if (net->type != VIR_DOMAIN_NET_TYPE_NETWORK) {
+ if (net->type != VIR_DOMAIN_NET_TYPE_NETWORK &&
+ net->type != VIR_DOMAIN_NET_TYPE_BRIDGE) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("Specified network adapter type is not "
"supported by Parallels Cloud Server."));
I really, really hate how the whole 'is this configuration supported'
thing is handled in parallels. Instead of enumerating what it does not
know, it should do it the other way round. Do a positive checking, if
configuration is supported. Then, even if we introduce yet another
device, or device attribute in other hypervisors, we don't need to
update parallels driver (which we permanently keep forgetting about).
I also don't like, that this function will fail, if some unsupported
option is provided. It was long time ago when Peter told me, that I
should report error, if there are some unsupported parameters:
https://www.redhat.com/archives/libvir-list/2012-July/msg00602.html.
It should be possible to define a domain if some unsupported parameters
are provided, which wouldn't affect domain behaviour very much.
ACK though.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
Dmitry Guryanov
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list