Re: [libvirt] [PATCH 3/4] parallels: fix parallelsDomainDefineXML for existing containers

On 120912 16:14:47, Daniel Veillard wrote: > On Mon, Sep 10, 2012 at 07:22:44PM +0400, Dmitry Guryanov wrote: > > Fix code, which checks what is changed in virDomainDef structure. > > It looks slightly different for containers and VMs: containers haven't > > boot devices, but have init path > > > > Signed-off-by: Dmitry Guryanov <dguryanov(a)parallels.com&gt; > > --- > > src/parallels/parallels_driver.c | 42 ++++++++++++++++++++++++++++--------- > > 1 files changed, 32 insertions(+), 10 deletions(-) > > > > diff --git a/src/parallels/parallels_driver.c b/src/parallels/parallels_driver.c > > index ace75a6..fd6ba88 100644 > > --- a/src/parallels/parallels_driver.c > > +++ b/src/parallels/parallels_driver.c > > @@ -1484,24 +1484,46 @@ parallelsApplyChanges(virDomainObjPtr dom, virDomainDefPtr new) > > return -1; > > } > > > > - /* we fill only type and arch fields in parallelsLoadDomain, so > > - * we can check that all other paramenters are null */ > > + /* we fill only type and arch fields in parallelsLoadDomain for > > + * hvm type and also init for containers, so we can check that all > > + * other paramenters are null and boot devices config is default */ > > + > > if (!STREQ_NULLABLE(old->os.type, new->os.type) || > > !STREQ_NULLABLE(old->os.arch, new->os.arch) || > > So here you implicitely allow an update where the new os.type or > os.arch would be NULL, I assume that any definition in the system > should have those set, right ? old->os.type and old->os.arch are always non-NULL, because we set them in parallelsLoadDomain and don't change later. So if new->os.type/arch is NULL or not equal to old - we report error.

> Postponed with the indentation fix waiting for the 4th patch to be > resubmitted,