Hi, I'm making a patch to provide a changing allocation dynamically and statically without keeping state at the library. And this is still uncompleted works, but I would like to hear your comments.

Hi Daniel

I'm sorry I might be disrespectful a little...

I understood descriptions of domains, and I will think over again with members of my team. I appreciate your explaining. thanks a lot !

Hi Daniel, Thank you for your proposal ! I considered the way with it. On Fri, 27 Apr 2007 10:35:15 -0400 Daniel Veillard wrote: > So I have a problem with this, and I suggest to isolate configuration > file APIs, which in practice would mean client code a bit more verbose > but keeping the API simpler. > We have a long week-end ahead, I will try to get back with more complete > proposal, but I could see a set of API like: > > proposal 1: > > - create a config from a string (or file) > we could autodetect the kind of configs here and automatically support > XML, sexpr, old Xen config files, and also VMWare-like ones > - create a config from a running domain (like virDomainGetXMLDesc does) > - modify values from a config > - get a value from a config > - save a config (as libvirt XML) in a string or file > > The main drawback of proposal 1 is that it increase the API, but would make > clear what kind of objects are been managed, i would also allow more specific > configuration only option in the future. I think that the proposal is good to keep the API simple, though, the number of API increases.

Here is an example of the interface. We could provide new API (like virDomainSetMemoryConfig), and use only it for not running domain.

# virsh setmem foo 200

I think this is the better way than I suggested before. How does this look ?

On Thu, 10 May 2007 12:36:30 -0400 Daniel Veillard wrote: > Well I have though about it more, and I'm afraid that proposal 1 makes things > more complex due to the duplication of APIs. I think proposal 2 makes more > sense, i.e. be able to create a Domain object from a config file. We just need > to add new API to generate an xmlDomainPtr from those data, then store the > path or data in the domain structure, and also a new API to be able to > differentiate whether a domain is about a running domain or just the config. Can I ask something ? That means adding xmlDomainPtr to virDomainPtr, like this ? struct _virDomain { unsigned int magic; /* specific value to check */ int uses; /* reference count */ virConnectPtr conn; /* pointer back to the connection */ xmlDomainPtr conf; <----this one char *name; /* the domain external name */ int id; /* the domain ID */ unsigned char uuid[VIR_UUID_BUFLEN]; /* the domain unique identifier */ };

> The problem is that one need to add one such API for every aspect of the > domain configuration, if it was only memory that would not be that bad > but we ultimately want to be able to modify everything. Yes, I would like to modify another values, too. There are vcpus, disk, network interface, vncport...etc.

> I think it's better to allow the duality of virDomainPtr, accepting > it to be either a representation for a running domain or a representation > of the associated configuration file. The fact that with new versions of Xen > one can change into the other doesn't sound something that will be > common to other engines, and as you noted it actually makes things > harder because if you call the API you don't know a-priori without > checking the current state which aspect will be modified. > So we need to separate the two states, but if we can keep the > same APIs for most of the modification entry points and just add > a few call to create the configuration domains and being able to > ask if a domain is about a config or about a running one. Now, the result of command seems not to be consistent when the domain is not running. So I think if we can separate the API between running domain and not running domain, we get the consistent result.

On Fri, 11 May 2007 14:06:07 -0400 Daniel Veillard wrote: > > Can I ask something ? That means adding xmlDomainPtr to virDomainPtr, > > like this ? > > > > struct _virDomain { > > unsigned int magic; /* specific value to check */ > > int uses; /* reference count */ > > virConnectPtr conn; /* pointer back to the connection */ > > xmlDomainPtr conf; <----this one > > char *name; /* the domain external name */ > > int id; /* the domain ID */ > > unsigned char uuid[VIR_UUID_BUFLEN]; /* the domain unique identifier */ > > }; > > I am not sure we can bind the two like this in general. That's something > which would be possible if you use a configuration and then ask to start > the domain (in a way similar to virDomainCreate() but from a configuration). > But we can't expect to have a configuration everytime we get a Domain. > If you start virsh and list the domains you will get the virDomainPtr > of running domains, but you won't be able to guess in general where the > config file for them would be. Does that make sense ? Hmm, sorry but I do not really understand why the xmlDomainPtr is needed because I do not want to use "config file". To give an example, I would like to achieve in a manner similar to the way the virt-manager remove the device. --- virtManager/domain.py:remove_device 1. dumpXML 2. modify the defined XML 3. define But, there are the necessary information that is Xen-specific or should not be shown to all-user in sxp-format, and we should not have such information in XML. So I selected using sxp-format instead of XML, i.e. modifying the config at lower layer (xend_internal.c) that I proposed before. --- xend_internal.c 1. root = sexpr_get(domain->conn, "/xend/domain/%s?detail=1",domain->name); 2. snprintf(buf, sizeof(buf), "%lu", memory >> 10); 3. sexpr_chg_node(root, "domain/memory", buf, sizeof(buf)); /* new API */ 4. ret = xend_op(domain->conn, "", "op", "new", "config", buf, NULL); > > Now, the result of command seems not to be consistent when the domain is > > not running. So I think if we can separate the API between running > > domain and not running domain, we get the consistent result. > > I'm not sure I understand. Say you use virDomainSetMemory() with a > very large value. I agree that if you target a running domain you may > get an error due to lack of memory on the host, while running the > same call on a virDomainPtr addressing a configuration file you are > not likely to see such error raised. Are you concerned by this kind of > difference in behaviour or something else ? And my concern is that there are 2 kinds of return (some command returns success but some command returns failure) when executing the virsh command while the domain is not running, because of depending on Xen. For example, there are following result for current Xen: success : setmem, setmaxmem failure : setvcpus, vcpupin, device attach/detach(*) "device attach/detach" is a command being proposed by Sunou-san now, but that will return failure because "xm block-attach/detach" is failed while the domain is not running. This might be Bug of Xen, so we should approach this to Xen. But also I think we can choose the way that has least impact of Xen Bug. What do you think about this ? Thanks, Saori Fukuta -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

It sounds to me like the real solution would be to either fix virDomainGetXMLDesc to return these missing fields, or add another call to get them, or (for the password) to store it elsewhere. How about loading the original config XML and the XML from the running domain (virDomainGetXMLDesc), and then updating the config XML with only certain fields from the running domain?

On Fri, May 11, 2007 at 10:59:37PM +0900, Saori Fukuta wrote: > Hi, > > Thank you for your comment ! > > On Fri, 11 May 2007 13:33:57 +0100 "Richard W.M. Jones" wrote: > > It sounds to me like the real solution would be to either fix > > virDomainGetXMLDesc to return these missing fields, or add another call > > to get them, or (for the password) to store it elsewhere. > > > > How about loading the original config XML and the XML from the running > > domain (virDomainGetXMLDesc), and then updating the config XML with only > > certain fields from the running domain? > > Well, I'm not sure about the meaning of "original config XML" but I do > not think it is possible because the original config file might be not XML > like a Xen config file. Xen does not have XML file. > Is this right ? Yes I'm not sure that in general you can always hope to reconstruct the content of the configuration file just from a pointer to a running instance,

On Fri, May 11, 2007 at 07:15:33PM +0100, Daniel P. Berrange wrote: > > If the guest was created by libvirt, then I consider it a bug if the XML > dump does not allow re-creation in exact same config. > > If the guest was created by non-libvirt app, then there may be some xen > specific bits we don't support in libvirt. So be it - there are some things > we simply don't want to support. For any of the latter case, we can at > least evaluate whether it makes sense to support them throughout libvirt, > and/or accept patches.

> The main flaw I see currently is that the vncpassword is missing from the > XML. We left that out for security obviously. We definitely have to exclude > it if using a read-only connection. For a read-write connection we should > probably continue to exclude it by default, since apps often write the XML > dump to logfiles. We do fortunately have a (currently unused) flags argument > to virDomainGetXMLDesc > > char * virDomainGetXMLDesc (virDomainPtr domain, > int flags); > > I propose we add a flag LIBVIRT_XML_INCLUDE_SENSITIVE or something like > that. If that flag were used, then we could include the password in the > returned XML. Any apps using that flag would be aware that the XML should > be treated as sensitive & thus not logged. On this subject of XML dumps for live VMs, there is the option that the live VM config will be different from the one on disk. Currently the virDomainGetXMLDesc will always give you the live config if the guest is running, and the disk config if the guest is not running. The option missing here is obviously a way to get the disk config if the guest is running. Now we have this convenient flags arg here still which we could use: char *livexml = virDomainGetXMLDesc(dom, 0); char *diskxml = virDomainGetXMLDesc(dom, VIR_DOMAIN_XML_INACTIVE); Once you have the real diskxml, then you can update it & use the virDomainDefineXML(dom, diskxml) to re-write it on disk, virDomainCreate(dom, diskxml) if you want to create a VM with the new config, without actually updating the config on disk

> I think that would be a waste because we would miss an opportunity to get > new customers. I personally want to support the guest was created by non-libvirt > app too. That is almost correct. We do support management of guests that were created by non-libvirt based applictions - if the config options they used are capable of being expressed in terms of libvirt XML. Now there are certainly a number of Xen configuration options that we don't currently support in libvirt. We've perhaps got the 75% common case that people use. I don't think we'll ever get 100% because there are some things that are really very Xen specific, but that shouldn't stop us aiming to improve our coverage. There's plenty of scope for more work to let us deal with 95%+ of the Xen config options. IMHO, not hitting the remaining few % is a worthwhile tradeoff given the huge benefits of having a config representation which isn't tied to Xen, particularly if that remaining 5% is the type of niche edge case config rarely used.

As always, I'd welcome suggestions & patches for representing more of the Xen config options in the generic XML format. The obvious big outstanding areas we've currently got are, USB (we've already agreed on format, now just need to implement it), serial/parallel devices (cf other thread suggesting a way to represent it), sound devices (no suggestions yet, but several end-user feature requests).