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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Dmitry Guryanov