[Libvirt-cim] [PATCH 6 of 6] Make VSMS not parse the InstanceID of a RASD, but rather use the proper fields

[Dan Smith]

KR> The default network pool isn't guaranteed to be present. In such a
KR> case, the creation of a guest using "network" will fail.

Good point.

KR> Would it be possible to print a meaningful error message in this
KR> case?  We currently print "Failed to create domain" which isn't
KR> very descriptive.

Yeah, we're pretty deep in the plumbing here, I'll see how I can
improve that.

KR> Should we use the libvirt API to attempt to discover an available
KR> pool?

We'd need to establish a connection to do that, which seems a little
hefty.  I wonder what happens if we request a 'network' type without
specifying the network we want?  Maybe it will take the first one...

KR> Also, why define val as "NetworkPool/default" just to strip out
KR> the "NetworkPool/" piece later on?  Is this for clarity /
KR> readability reasons?

Yeah, it lets the rest of the code assume you've got a valid Pool
InstanceID in your PoolID, which is what would happen if you had
allocated it properly with AC.  This makes it effective take the exact
same path for the default case, which I think is a reasonable
expectation.

KR> Why does this value differ from the random value assigned in the
KR> default NetRASD?

Well, because I was thinking that if you didn't specify a MAC and/or
you didn't go through the allocation step with AC.  However, I'm not
sure this is a sane way to handle it, so it's good you brought it up.

KR> I guess this brings up the question - should we be pulling these
KR> defaults from the default RASDs?  Or should we not assume defaults
KR> at all and fail if an attribute we need isn't supplied?

I tend to want to say that the DefineSystem() call is not an
allocation step.  You either specify the resources you want, or that
you have allocated from AC, or it's an error.  There are some fields
of a RASD that aren't required, of course, but there are some that
should be mandatory.  In the network RASD, I think MAC would count as
mandatory.

If later, we wanted to have the ability to control the MAC allocation
per pool (say, to check to see if a randomly-generated MAC was already
in use in the pool), doing it automatically here would be a little
harder to reconcile, I think.  My feeling is that failure to specify
something this fundamental in your domain config should be an error.
What do others think?

KR> The problem I see is that the profiles don't explicitly define
KR> what attributes are required.  It seems that the default RASDs
KR> define this for us in some cases, but not all (see VirtualDevice
KR> and Address for disk devices).  Should these values be placed in
KR> the default RASDs as well?

Well, I'm not sure that it makes sense to have a default path for the
default DiskRASD, although a default VirtualDevice of 'xvda' for xen
and 'hda' for KVM seems sane to me.

KR> Either way, I'm not sure it's meaningful to use a default value
KR> for something such as the mac address.  Maybe a distinction could
KR> be made for things like network pool, we can use a default (a
KR> statically defined one as included above, or a discover a pool if
KR> available).  For something like a mac address, which really should
KR> be supplied by the user, we can fail.

Yeah, I think that if they specify the MAC and don't specify a pool,
it makes sense to use the default (or first-found pool).  I'll check
into the libvirt behavior mentioned above and post another round for
comments. 

Thanks!

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20080410/953f990f/attachment.sig>