[Xen-API] Additional draft API comments

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Some comments sent to me from Charles Coffing ...

-----

The username/password authentication is "as defined by the Xen administrator".  
So it sounds like there will be extra setup needed before the physical machine will be 
manageable remotely.  Probably not a comment for the document, but something for us to 
remember.

What if the client does not log out (does not call "Session.Logout")?  I assume 
there must be a timeout, but I see no mention of one (timeout error codes, etc).

Is the session_id lifetime tied to the lifetime of the HTTP connection, or can 
it span multiple HTTP connections?

Is it valid if the same user attempts to log in multiple times, simultaneously, 
on the same physical machine?

enum vm_power_state doesn't have any state that represents a crashed VM.  Suppose 
on_crash_behavior is "preserve" and the VM crashes; what is vm_power_state?

Describe any limitations on what "name/label" (in class VM) may be.  Seems like 
lower-level layers had some limitations.

How can a VM class have a "VCPUs/policy" setting?  I thought that was set per physical 
machine, so how can the VM dictate?  Further, consider the case when the VM migrates to a new 
machine, potentially using a different scheduling policy, so that the VM's "VCPUs/params" 
don't make sense.

"platform/std_VGA" setting on the VM class shouldn't be a bool.  People have 
complained about the age of standard VGA and Cirrus Logic bottleneck performance (don't 
know if this is true, but I've heard the complaint).  Assuming better virtual video 
drivers are developed, you'll have to break this interface to support new video drivers.  
Perhaps it should be a string.

The "kernel/*" settings of the VM class also need to have the ability to name the virtual 
device that contains the kernel/initrd (to support domUloader).    Maybe 
"kernel/boot_device"?

How to "kernel/args" and "grub/cmdline" differ?  I assume the former maps to the current 
"extra" setting in the config file; what is the latter?

Cloning (section 2.6.2) feels like a too high-level feature to put that low in the stack. 
 Xen/xend don't know anything about my storage setup, so how can it "exploit 
capabilities of the underlying storage repository"?  (Okay, I see the storage 
repository class later, but I'm still trying to decide if it's appropriate.)

I see no way to support the current "xm create -c foo" behavior.  (Suppose I want to see the kernel 
boot messages for debugging a boot problem.)  Seems like the VM class needs a "console" field, 
similar to "platform/serial", where you can connect the console to a pty.  Then create the VM in a 
paused state, connect your viewer to the pty, and unpause.

Both "clean_shutdown" and "clean_reboot" say "this may not be supported".  How do I know? 
 Will I get an error code indicating such?  Timeouts are dangerous -- there's no way to know what a 
"reasonable" shutdown timeout would be.

The "suspend" command doesn't let me specify where on disk to place the VM's image.  It 
should.  Ditto for "resume".

I don't care about "software_version" in class host.  I want to know if the ABI is compatible.  Is 
version "3.0.2" compatible with version "3.0.3"?  No way for a management tool to know.  
But abi_version 3 == abi_version 3, clearly.

Can I query the current state of the host?  (enabled/disabled/...)  I don't see an 
"enum host_state".

2.8.1:  Unclear what "number" is.  Are "physical CPUs" just # of packages?  # of cores?  
Seems that "logical CPUs" would be more useful.

What does it mean for all these fields to be "RW"?  Example, section 2.10.1, class VIF.  I start up a VM, then change 
"device" from "eth0" to "eth1".  Is that non-sensical, or is that a hotplug event to the VM?  MAC 
is even worse, because I don't think that would be a hotplug event.  Shouldn't those (and others) be only settable when the VM 
starts ("ROins")?

This seems to just be a runtime API.  Are there plans for the additional tools 
that are implied?  (e.g., how do I create/list/delete these users?)

Migration needs to be addressed

Architectures need to be addressed, more than just the CPU flags.  VM might require IA64, for example.  Perhaps this is 
treated as a CPU flag... but if so, also add "generic x86 32 bit" flag to require a certain base 
architecture, not just "P3" / "P4" / "K8", etc.



_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api