Re: [Qemu-devel] [PATCH 1/1] If user doesn't specify a uuid, generate a random one

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/26/2012 10:13 AM, Serge E. Hallyn wrote:
> Currently, if the user doesn't pass a uuid, the system uuid is set to
> all zeros.  This patch generates a random one instead.
>
> Is there a reason to prefer all zeros?  If not, can a patch like this
> one be applied?
>
> Signed-off-by: Serge Hallyn<serge.hallyn@canonical.com>

The other hypervisors don't have a concept of a transient guest like QEMU does.

There is no state preserved between invocations of QEMU.

Setting a random UUID doesn't seem like the right answer to me as it would 
potentially break Windows VMs.

Perhaps if the DMI UUID isn't set, you could look at the root filesystem's UUID?

Not all platforms have a notion of platform UUID so as Ubuntu supports more 
architectures, this problem would have to be dealt with eventually.

Regards,

Anthony Liguori

> ---
>   vl.c |   11 +++++++++++
>   1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 112b0e0..2b53b62 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -247,7 +247,9 @@ int nb_numa_nodes;
>   uint64_t node_mem[MAX_NODES];
>   uint64_t node_cpumask[MAX_NODES];
>
> +#include<uuid/uuid.h>
>   uint8_t qemu_uuid[16];
> +bool uuid_set = false;
>
>   static QEMUBootSetHandler *boot_set_handler;
>   static void *boot_set_opaque;
> @@ -3030,6 +3032,7 @@ int main(int argc, char **argv, char **envp)
>                               " Wrong format.\n");
>                       exit(1);
>                   }
> +                uuid_set = true;
>                   break;
>   	    case QEMU_OPTION_option_rom:
>   		if (nb_option_roms>= MAX_OPTION_ROMS) {
> @@ -3200,6 +3203,14 @@ int main(int argc, char **argv, char **envp)
>           exit(0);
>       }
>
> +    if (!uuid_set) {
> +        uuid_t uuid;
> +        uuid_generate(uuid);
> +        for (i = 0; i<  16; i++) {
> +            qemu_uuid[i] = uuid[i];
> +        }
> +    }
> +
>       /* Open the logfile at this point, if necessary. We can't open the logfile
>        * when encountering either of the logging options (-d or -D) because the
>        * other one may be encountered later on the command line, changing the