On Mon, Jun 12, 2006 at 06:52:57PM -0400, Daniel Veillard wrote:
On Mon, Jun 12, 2006 at 11:19:00PM +0100, Daniel P. Berrange wrote:
> * Driver method hookup. The libvirt.c file has alot of methods which are
> either not hooked up to the driver backend, or hooked up, but still have
> duplicated (redundant?) Xen specific calls. Here is the complete status:
Okay, I need to clean them up, please bugzilla this I will fix this soonish.
> virDomainDestroy
>
> - Does not call out to driver backends, hardcodes XenD & Xen HV
>
bad need fixing to call the driver entry point.
> virDomainSuspend
>
> - Does not call out to driver backends, hardcodes XenD & Xen HV
>
>
same as previous
> virDomainResume
>
> - Does not call out to driver backends, hardcodes XenD & Xen HV
>
same as previous
> virDomainShutdown
>
> - Does not call out to driver backends, hardcodes XenD
>
same as previous
>
> virDomainReboot
>
> - Does not call out to driver backends, hardcodes XenD
>
same as previous
I'm attaching an initial patch which implements the driver backend calls
for these five methods.
I've tested that suspend & resume work, but my hardware died before I fully
tested the other methods. I've got a couple questions before proceeding in
any case:
1. In all of these methods I followed example from virDomainSetMemory and
put in
if (domain->conn->flags & VIR_CONNECT_RO)
return (-1);
This prevents these methods working with a 'read only' connection, however,
this is a deviation from previous semantics. Even with a read only connection,
XenD will let arbitrary unprivileged user shutdown/suspend/resume/etc a
domain, so by putting this VIR_CONNECT_RO check in we'd be preventing an
operation which used to work.
However, IMHO this is a good thing, because it can be considered a *HUGE*
security hole / denial of service attack, that unprivileged users can shutdown
reboot, suspend, etc domains via XenD with no authentication. When this hole
is eventually plugged, these methods would cease to work with a read only
connection, so long term we'd end up in the same situation. Thus this patch
could be considered a 'pre-emptive' solution.
2. The current implementation of shutdown & reboot methods calls the same code
twice in a succession:
/*
* try first with the xend daemon
*/
ret = xenDaemonDomainShutdown(domain);
if (ret == 0) {
domain->flags |= DOMAIN_IS_SHUTDOWN;
return (0);
}
/*
* this is very hackish, the domU kernel probes for a special
* node in the xenstore and launch the shutdown command if found.
*/
ret = xenDaemonDomainShutdown(domain);
if (ret == 0) {
domain->flags |= DOMAIN_IS_SHUTDOWN;
}
What was the reason to call xenDaemonDomainShutdown twice ? With my
change to use the driver backends, it will only be called once. So I want
to make sure I'm not missing an edge case here.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|