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@us.ibm.com