The extra check whether (connect|bind)(Host|Service) was set is
required because for UDP chardev there can be two source elements.
Without the check there could be a memory leak.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In order to ensure that the default protocol is RAW, explicitly
assigning VIR_DOMAIN_CHR_TCP_PROTOCOL_RAW = 0.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Currently we accept and correctly parse this chardev XML:
...
<channel type='tcp'>
<source mode='connect'/>
<source mode='bind' host='localhost'/>
<source service='4567'/>
<target type='virtio' name='test'/>
</channel>
...
The parsed formatted XML is:
...
<channel type='tcp'>
<source mode='connect' host='localhost' service='4567'/>
<target type='virtio' name='test'/>
</channel>
...
That behavior is super wrong and should not be allowed. If you notice
the current parse takes the first found attribute and uses that value,
so for example from the "<source mode='bind' host='localhost'/>" only
the "host" attribute is used. It works the same way for all possible
attributes that we are able to parse for source element.
This patch enforces providing only one source element for all character
devices, only for UDP type we allow to provide two source elements
since you can specify both modes.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Since its introduction in commit 874e65aa, if someone requests:
<os><bios useserial="yes"/><os/>
we report an error if we cannot successfully count the number
of serial devices via an XPath query.
Instead of fixing the check (and moving it to the validation phase,
to prevent existing domains from disappearing), drop it completely.
For QEMU, the number of serials is checked when building the command
line.
I mistakenly thought pSeries guests supported 32 PHBs,
but it turns out they only support 31. Validate the
target index accordingly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1479647
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Validation should happen after parsing, so the proper
location for it is virDomainControllerDefValidate()
rather than virDomainControllerDefParseXML().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Some failures of the post parse callback can be tolerated. This is
specifically desired when loading the configs of existing VMs. In such
case the post parse callback should not really be modifying anything
in the definition.
This patch adds a parse flag VIR_DOMAIN_DEF_PARSE_ALLOW_POST_PARSE_FAIL
which will allow the callbacks to report non-fatal failures by returning
a positive return value. In such case the field 'postParseFailed' in the
domain definition is set to true, to notify the drivers that the
callback failed and possibly needs to be re-run.
Post parse callbacks will need to be able to signal that they failed
non-fatally. This means that we need to return the value returned by the
callback without modification.
Some drivers use def-specific private data across callbacks (e.g.
qemuCaps in the qemu driver). Currently it's mostly allocated in every
single callback. This is rather wasteful, given that every single call
to the device callback allocates it.
The new callback will allocate the data (if not provided externally) and
then use it for the VM, address and device post parse callbacks.
Add yet another post parse callback, which is executed prior the real
one without @parseOpaque. This is meant to set basics before
@parseOpaque (in case of the qemu driver qemuCaps) can be allocated.
This callback will allow to optimize passing of custom parseOpaque
through the callbacks.
Back in the day when I was implementing QoS for networks there
were no self inflating virBitmaps. Only the static ones.
Therefore, I had to allocate the whole 8KB of memory in order to
keep track of used/unused class IDs. This is rather wasteful
because nobody is ever gonna use that much classes (kernel
overhead would drastically lower the bandwidth). Anyway, now that
we have self inflating bitmaps we can start small and allocate
more if there's need for it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Rename the variable, recent review requested just use of @filter,
so be consistent throughout.
NB: Also change the virNWFilterPtr to be @nwfilter to not conflict
with the renamed variable.
Use the structure names in the @data setup - makes it easier than
going back to find the struct fields to make sure the order of the
data is correct.
Signed-off-by: John Ferlan <jferlan@redhat.com>
To be consistent with the API definition, use the @maxnames instead
of @nnames when describing/comparing against the maximum names to
be provided for the *ConnectList[Defined]Networks APIs.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move the virObjectRef in virNetworkObjAssignDefLocked to after
the virHashAddEntry to make it "clearer" why the @ref is being
incremented. Upon return from the ObjNew we will have 1 ref on
the object already, adding it to the hash table requires the
increment.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In preparation to privatize the virNetworkObj - create an accessor function
to get the current @persistent value. Also change the value to a bool rather
than an unsigned int (since that's how it's generated anyway).
Signed-off-by: John Ferlan <jferlan@redhat.com>
In order to privatize the virNetworkObj create accessors in virnetworkobj
in order to handle the get/set of the active value.
Also rather than an unsigned int, convert it to a boolean to match other
drivers representation and the reality of what it is.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In preparation for making the object private, create a couple of API's
to get the obj->def & obj->newDef and set the obj->def.
While altering networkxml2conftest.c to use the virNetworkObjSetDef
API, fix the name of the variable from @dev to @def
Signed-off-by: John Ferlan <jferlan@redhat.com>
Change the variable name to be a bit more descriptive and less confusing
when used with the data.network.actual->class_id.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In preparation for making the object private, create/use a couple of API's
to get/set the obj->dnsmasqPid and obj->radvdPid.
NB: Since the pid's can sometimes changed based on intervening functions,
be sure to always fetch the latest value.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since we can only ever have one reference to obj->macmap, rather
than only clearing obj->macmap during virNetworkObjUnrefMacMap
(e.g. virtual network from networkShutdownNetwork), let's just
unconditionally clear the obj->macmap to ensure that some future
change that created it's own reference to obj->macmap wouldn't
have that reference disappear if virNetworkObjDispose got called.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In preparation for having a private virNetworkObj - let's create/move some
API's that handle the obj->macmap. The API's will be renamed to have a
virNetworkObj prefix to follow conventions and the arguments slightly
modified to accept what's necessary to complete their task.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than overload virObjectUnlock as commit id '77f4593b' has
done, create a separate virObjectRWUnlock API that will force the
consumers to make the proper decision regarding unlocking the
RWLock's. Similar to the RWLockRead and RWLockWrite, use the
virObjectGetRWLockableObj helper. This restores the virObjectUnlock
code to using the virObjectGetLockableObj.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Instead of making virObjectLock be the entry point for two
different types of locks, let's create a virObjectRWLockWrite API
which will only handle the virObjectRWLockableClass objects.
Use the new virObjectRWLockWrite for the virdomainobjlist code
in order to handle the Add, Remove, Rename, and Load operations
that need to be very synchronous.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since the class it represents is based on virObjectRWLockableClass
and in order to make sure we differentiate just in case anyone somehow
believes they could use virObjectLockRead for a virObjectLockableClass,
let's rename the API to use the RW in the name. Besides the RW locks
refer to pthread_rwlock_{init|rdlock|wrlock|unlock|destroy} while the
other locks refer to pthread_mutex_{init|lock|unlock|destroy}.
Signed-off-by: John Ferlan <jferlan@redhat.com>
