[libvirt] autostarting xend domains
Hi, I found that support for setting autostart parameters for xend managed guests has been added to libvirt (https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html) So I tried that but failed with virsh's autostart command (and also virt-manager) like this: virsh # autostart saruman libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: VM name 'saruman' already exists as domain 32") libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr 6508560 error: Failed to mark domain saruman as autostarted So yes, the domain is indeed running but I understood it should be changeable during a domain's lifetime. Any ideas? That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation. Thanks, Wolfgang
Wolfgang Rosenauer wrote:
Hi,
I found that support for setting autostart parameters for xend managed guests has been added to libvirt (https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html)
So I tried that but failed with virsh's autostart command (and also virt-manager) like this:
virsh # autostart saruman libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: VM name 'saruman' already exists as domain 32") libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr 6508560 error: Failed to mark domain saruman as autostarted
So yes, the domain is indeed running but I understood it should be changeable during a domain's lifetime.
Any ideas? That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation.
Thanks, Wolfgang
Hmm, I thought redefining the sexpr in place was an a-okay thing to do, and this worked on my f8 machine. I'll look into this. Thanks, Cole
On Tue, May 20, 2008 at 10:00:50AM -0400, Cole Robinson wrote:
Wolfgang Rosenauer wrote:
Hi,
I found that support for setting autostart parameters for xend managed guests has been added to libvirt (https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html)
So I tried that but failed with virsh's autostart command (and also virt-manager) like this:
virsh # autostart saruman libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: VM name 'saruman' already exists as domain 32") libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr 6508560 error: Failed to mark domain saruman as autostarted
So yes, the domain is indeed running but I understood it should be changeable during a domain's lifetime.
Any ideas? That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation.
Thanks, Wolfgang
Hmm, I thought redefining the sexpr in place was an a-okay thing to do, and this worked on my f8 machine. I'll look into this.
Yes it is an OK thing todo. It is explicitly supported as it is *required* in order todo installations - we boot the guest with the install config, and defnie the guest with its persistent config. What exact version of Xen is being used here ? It looks like it has overzealous duplicate checking Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
On Tue, May 20, 2008 at 10:00:50AM -0400, Cole Robinson wrote:
I found that support for setting autostart parameters for xend managed guests has been added to libvirt (https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html)
So I tried that but failed with virsh's autostart command (and also virt-manager) like this:
virsh # autostart saruman libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: VM name 'saruman' already exists as domain 32") libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr 6508560 error: Failed to mark domain saruman as autostarted
So yes, the domain is indeed running but I understood it should be changeable during a domain's lifetime.
Any ideas? That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation.
Thanks, Wolfgang
Hmm, I thought redefining the sexpr in place was an a-okay thing to do, and this worked on my f8 machine. I'll look into this.
Yes it is an OK thing todo. It is explicitly supported as it is *required* in order todo installations - we boot the guest with the install config, and defnie the guest with its persistent config. What exact version of Xen is being used here ? It looks like it has overzealous duplicate checking
The Xen package is called 3.1.0_15042 and is packaged with openSUSE 10.3. Thanks, Wolfgang
Daniel P. Berrange wrote:
On Tue, May 20, 2008 at 10:00:50AM -0400, Cole Robinson wrote:
Wolfgang Rosenauer wrote:
I found that support for setting autostart parameters for xend managed guests has been added to libvirt (https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html)
So I tried that but failed with virsh's autostart command (and also virt-manager) like this:
virsh # autostart saruman libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: VM name 'saruman' already exists as domain 32") libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr 6508560 error: Failed to mark domain saruman as autostarted
So yes, the domain is indeed running but I understood it should be changeable during a domain's lifetime.
Any ideas? That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation.
Thanks, Wolfgang Hmm, I thought redefining the sexpr in place was an a-okay thing to do, and this worked on my f8 machine. I'll look into this.
Yes it is an OK thing todo. It is explicitly supported as it is *required* in order todo installations - we boot the guest with the install config, and defnie the guest with its persistent config. What exact version of Xen is being used here ? It looks like it has overzealous duplicate checking
I just found the following patch which is applied to Xen 3.1 on openSUSE which sounds like the culprit. If you can confirm that I'm happy to report a bug over at openSUSE. # HG changeset patch # User kfraser@localhost.localdomain # Date 1180086787 -3600 # Node ID a717cb2fac908ba82619ba52e34a2cc77942df4f # Parent 9073caff4b63490bc63bbe2b0b48fd06cc47d6c6 xend: Fix checkname so that it detects duplicate domains. Signed-off-by: Mats Petersson <mats.petersson@amd.com> Index: xen-3.1-testing/tools/python/xen/xend/XendDomainInfo.py =================================================================== --- xen-3.1-testing.orig/tools/python/xen/xend/XendDomainInfo.py +++ xen-3.1-testing/tools/python/xen/xend/XendDomainInfo.py @@ -2069,7 +2069,7 @@ class XendDomainInfo: raise VmError('Invalid VM Name') dom = XendDomain.instance().domain_lookup_nr(name) - if dom and dom.info['uuid'] != self.info['uuid']: + if dom and dom.domid != self.domid: raise VmError("VM name '%s' already exists%s" % (name, dom.domid is not None and
On Tue, May 20, 2008 at 04:20:44PM +0200, Wolfgang Rosenauer wrote:
Daniel P. Berrange wrote:
I just found the following patch which is applied to Xen 3.1 on openSUSE which sounds like the culprit. If you can confirm that I'm happy to report a bug over at openSUSE.
Yes, this changeset was utterly bogus.
# HG changeset patch # User kfraser@localhost.localdomain # Date 1180086787 -3600 # Node ID a717cb2fac908ba82619ba52e34a2cc77942df4f # Parent 9073caff4b63490bc63bbe2b0b48fd06cc47d6c6 xend: Fix checkname so that it detects duplicate domains. Signed-off-by: Mats Petersson <mats.petersson@amd.com>
We reverted it upstream and the two they actually want are changeset: 15451:a86cf1d18625 user: Keir Fraser <keir@xensource.com> date: Tue Oct 02 10:04:06 2007 +0100 files: tools/python/xen/xend/XendDomainInfo.py description: xend: Fix name/uuid uniqueness checks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> xen-unstable changeset: 15998:a345f989722649ba01701babf60e49517e910102 xen-unstable date: Tue Oct 02 10:01:10 2007 +0100 changeset: 15450:d92bb1cd352c user: Keir Fraser <keir@xensource.com> date: Tue Oct 02 10:03:28 2007 +0100 files: tools/python/xen/xend/XendDomainInfo.py description: xend: Fix name uniqueness check (revert xen-unstable 15168:a717cb2fac90). Changeset 15168:a717cb2fac90 altered check_name() in XendDomainInfo so that it compares domain IDs instead of UUIDs. This breaks a number of things - You can no longer use 'xm new' to define a persistent config file for a running guest. This breaks the key OS provisioning scenario where you boot a kenrel+initrd for the installer, and at the same time define a permanent config with pygrub. - It lets you define multiple inactive guests with different UUIDs, but the same name because all inactive guests have a domid of None. So you can now end up with multiple guests with same name, which is contrary to the goal implied by the patch which was name uniqueness. It is unclear from the original commit logs just what scenario it was trying to protect against, but the original checking of uniqueness based on UUID was correct & is what was used in previous releases XenD. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> xen-unstable changeset: 15973:8817a53c030f9c2c5f39fafad72aa9502342e7b3 xen-unstable date: Thu Sep 27 18:08:11 2007 +0100 Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Wolfgang Rosenauer