The rules for configuring the password are equivalent of those used
for HVM, but the actual guest config option is a little different as a
result of the recent refactoring of the PVFB config file syntax.
- If the 'vfb' option in the guest config has a 'vncpasswd' parameter
specified
- If the passwd is not zero length, use that
- Else run with no authentication (important as it enables
override of next rule)
- Else-if the xend-config.sxp has a password specified use that
- Else run with no authentication
Example configuration:
- To set an explicit guest password:
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,vncpasswd=123456"]
- To disable authentication, overriding any XenD configured
default password
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,vncpasswd="]
- To run with default XenD configured password (if any)
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0"]
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
On the c-bindings side the marshalling code converts the string representation to an enum value. A subsequent attempt to convert the enum from a string to an enum was causing a seg fault.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
the old bootloader settings.
We now have two mutually exclusive config groups HVM and PV, with HVM/boot
and PV/{bootloader,kernel,ramdisk,args,bootloader_args}.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
In some situations triggered by errors found on guest side,
the device will be held forever, due to the online flag being still
on. Detach operations mostly fails from this point on, as the backend
will not see frontend's state change anymore.
Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
It's a long story, but basically a small divergence in xenppc-unstable meant a
large number of changesets couldn't be directly imported to xen-unstable, so
this changeset includes all of them.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
They were inconsistently represented as strings or lists making it
difficult to know the type of the IP parameter for vifs. Since both xm
and DevController represents these as space separated strings, that is
what it will be stored as.
Signed-off-by: Alastair Tse <atse@xensource.com>
be returned by XENMEM_memory_map. Hook this into the domain builder.
Based on a patch by Glauber de Oliveira Costa <gcosta@redhat.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
Fix breakage with storing VIF and VBD refs, remove extraneous
debugging. Also fixing some type errors in default values for Xen API
if things are missing in XendConfig.
Signed-off-by: Alastair Tse <atse@xensource.com>
be performed on domains - new, start and delete. libvirt has had no-op
stub implementations of these APIs for a while & thus we'd enable their
use for Xen 3.0.4 builds. The new APIs are not currently exposed via the
existing SEXPR protocol, and since the new Xen-API protocol is unsupported
tech-preview for 3.0.4 we don't want to re-write against that just yet.
Thus the attached patch adds the 3 neccessary bindings for the SEXPR protocol
to allow the lifecycle functionality to be invoked. It also allows the 'state'
parameter to be specified when listing domains, so we can explicitly request
inactive domains if we know we're running against a 3.0.4 era XenD
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
incoming client requests. Since some requests can take non-trivial time
blocking out other clients in this way has bad consequences. The attached
patch makes XenD spawn a new thread to handle each incoming HTTP request.
This same approach is already taken in the XML-RPC service in XenD so I
don't anticipate any multi-thread issues (at least none which don't already
exist).
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
kfraser@localhost.localdomain