All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Daniel Stekloff <dsteklof@us.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, xen-devel@lists.sourceforge.net
Subject: Re: [PATCH] xenctld - a control channel multiplexing daemon
Date: Thu, 27 Jan 2005 08:19:37 -0600	[thread overview]
Message-ID: <41F8F879.9070808@codemonkey.ws> (raw)
In-Reply-To: <1106783940.6916.17.camel@DYN319619.beaverton.ibm.com>

Daniel Stekloff wrote:

>Can't we add functionality in Xen to make domain id's unique? When
>creating a new domain, the management tools can query the running (or
>even suspended) domains and find a unique domain id to use. I think you
>can tag a domains with their state. 
>
>  
>
Yes, I think eventually domains have to have some sort of UUID.  I'm not 
convinced that those can't be mapped onto the current domain ids by 
configuration tools though.

Here's a few scenarios to consider:

1) Someone suspends domain A to disk.  Domain A continues to run.  
Without stopping the original instance of Domain A, they start up the 
suspended image.

2) Someone takes the suspended form of Domain A and transfers it to 
another machine.  They start it up while Domain A is still running on 
another machine (creating a resource conflict).  If you're using DHCP, 
VMware can handle this scenario gracefully btw.

Are these errors?  I think it can be argued either way.

>I disagree. If we're to consider the larger management world, we need to
>lay the groundwork for managing domains now. I think the questions
>aren't easily answered, but I believe they should be. If we don't
>implement everything to start, we should at least have an idea where
>we're going. 
>  
>
I completely agree that we need to lay a groundwork.  I think 
large-scale domain management tools our outside the scope of the current 
focus.  What I'd like to see is an architecture that's good enough that 
when these large-scale domain management tools are finally worked out 
they can just be plugged in without rewriting the Xen management 
infrastructure.

I think the key to this is to keep things as simple as possible.  Don't 
require configuration files, don't rely on any sort of internal database 
for persistent state.

BTW, this discussion is great.  I'm very interested to see what others 
think of the broader management picture.

Regards,

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

  parent reply	other threads:[~2005-01-27 14:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 15:55 [PATCH] xenctld - a control channel multiplexing daemon Anthony Liguori
2005-01-21 16:39 ` Andrew Warfield
2005-01-21 17:19   ` Ronald G. Minnich
2005-01-21 19:59     ` Anthony Liguori
2005-01-21 20:44       ` Ronald G. Minnich
2005-01-21 21:14         ` Anthony Liguori
2005-01-21 20:54           ` Ronald G. Minnich
2005-01-21 21:28             ` Anthony Liguori
2005-01-21 21:37             ` Jared Rhine
2005-01-24 15:33               ` Ronald G. Minnich
2005-01-24 16:35                 ` Anthony Liguori
2005-01-24 16:55                   ` Jared Rhine
     [not found]                     ` <Pine.LNX.4.58.0501240957520.12186@bluesteel.lanl.gov>
2005-01-24 17:52                       ` Jared Rhine
2005-01-24 19:11                         ` Anthony Liguori
2005-01-24 19:07                     ` Anthony Liguori
2005-01-24 20:44                       ` B.G. Bruce
2005-01-26  2:31                       ` Jacob Gorm Hansen
2005-01-26  5:43                         ` Anthony Liguori
2005-01-26  6:59                           ` Jacob Gorm Hansen
2005-01-21 19:56   ` Anthony Liguori
2005-01-26  0:21   ` Michael Hohnbaum
2005-01-26 14:33     ` Andrew Warfield
2005-01-26 19:31       ` Anthony Liguori
2005-01-26 19:11         ` Andrew Warfield
2005-01-26 20:01           ` Anthony Liguori
2005-01-26 21:21             ` Daniel Stekloff
2005-01-26 22:28               ` Anthony Liguori
2005-01-26 21:57                 ` Daniel Stekloff
2005-01-26 21:49             ` Michael Hohnbaum
2005-01-26 22:57               ` Anthony Liguori
2005-01-26 23:55                 ` Michael Hohnbaum
2005-01-26 23:59                 ` Daniel Stekloff
2005-01-27  7:05                   ` Tobias Hunger
2005-01-27 14:19                   ` Anthony Liguori [this message]
2005-01-27 18:05                     ` Daniel Stekloff
2005-01-28  9:17                       ` Steven Hand
2005-01-28 16:56                         ` Daniel Stekloff
2005-01-27  0:13                 ` Daniel Stekloff
2005-01-27  3:48                 ` Daniel Stekloff
2005-01-26 23:36       ` Daniel Stekloff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41F8F879.9070808@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=aliguori@us.ibm.com \
    --cc=dsteklof@us.ibm.com \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.