qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 4/5] Use libuuid if available.
Date: Fri, 6 Jun 2008 10:18:55 +0100	[thread overview]
Message-ID: <20080606091855.GB25958@redhat.com> (raw)
In-Reply-To: <200806052322.17583.paul@codesourcery.com>

On Thu, Jun 05, 2008 at 11:22:17PM +0100, Paul Brook wrote:
> On Thursday 05 June 2008, Anthony Liguori wrote:
> > Gleb Natapov wrote:
> > > Anthony, thanks for the review.
> > >
> > > On Thu, Jun 05, 2008 at 10:18:15AM -0500, Anthony Liguori wrote:
> > >>> @@ -256,8 +260,14 @@ static void do_info_name(void)
> > >>>   static void do_info_uuid(void)
> > >>>  {
> > >>> +#ifdef CONFIG_UUID
> > >>> +    char uuid_str[37];
> > >>> +    uuid_unparse(qemu_uuid, uuid_str);
> > >>> +    term_printf("%s\n", uuid_str);
> > >>> +#else
> > >>
> > >> Just use a printf() string here again to eliminate the need for
> > >> CONFIG_UUID.
> > >
> > > So may be do not use libuuid at all and just write simple uuid string
> > > parsing function?
> >
> > For parsing, sure. But uuid generation requires implementing an
> > algorithm from an RFC. I think that warrants using libuuid.
> 
> Can we punt this to management tools? Having qemu create randomly different 
> machines seems like it's going to cause as many problems as it solves.  We've 
> already got things like MAC addresses which are fixed but need to be unique.

FYI, once you have the -uuid argument supported in QEMU, I'll update libvirt
to use it, and libvirt will always generate a random UUID when invoking QEMU
if the user didn't specify one explicitly. So for any management tool using
libvirt, there's no need for QEMU itself to generate random UUIDs.

Regards,
Daniel.
-- 
|: Red Hat, Engineering, London   -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 :|

  parent reply	other threads:[~2008-06-06  9:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-05  8:35 [Qemu-devel] [PATCH 1/5] Add OUT support to vmport Gleb Natapov
2008-06-05  8:35 ` [Qemu-devel] [PATCH 2/5] Add -uuid command line option Gleb Natapov
2008-06-05 15:13   ` Anthony Liguori
2008-06-05  8:35 ` [Qemu-devel] [PATCH 3/5] Add "info uuid" command to monitor Gleb Natapov
2008-06-05 15:14   ` Anthony Liguori
2008-06-05  8:35 ` [Qemu-devel] [PATCH 4/5] Use libuuid if available Gleb Natapov
2008-06-05 15:18   ` Anthony Liguori
2008-06-05 20:20     ` Gleb Natapov
2008-06-05 20:27       ` Anthony Liguori
2008-06-05 22:22         ` Paul Brook
2008-06-06  0:18           ` Anthony Liguori
2008-06-06  9:18           ` Daniel P. Berrange [this message]
2008-06-05  8:35 ` [Qemu-devel] [PATCH 5/5] Add support for UUID query to vmport interface Gleb Natapov
2008-06-05 15:19   ` Anthony Liguori

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=20080606091855.GB25958@redhat.com \
    --to=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).