Xen devel - Aug 2010 - [PATCH]: xl: use libuuid to generate random UUID''s

Link to libuuid in xl et al and bring in the header file. Use libuuid to
generate UUID''s which are actually UU and not merely pseudo-random :)

As a side-effect I have also used libuuid to generate more random MAC
addresses rather than keeping the old code and simply xoring getpid() in
to the PRNG seed.

diff -r 668f71224241 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Mon Aug 02 16:58:50 2010 +0100
+++ b/tools/libxl/Makefile	Wed Aug 04 18:48:10 2010 +0100
@@ -15,7 +15,7 @@ CFLAGS += -Werror -Wno-format-zero-lengt
 CFLAGS += -I. -fPIC
 CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
$(CFLAGS_libblktapctl)
 
-LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_libxenguest) $(LDFLAGS_libxenstore)
$(LDFLAGS_libblktapctl) $(UTIL_LIBS)
+LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_libxenguest) $(LDFLAGS_libxenstore)
$(LDFLAGS_libblktapctl) $(UTIL_LIBS) -luuid
 
 LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o
 LIBXL_OBJS = flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o
libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o
$(LIBXL_OBJS-y)
diff -r 668f71224241 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Aug 02 16:58:50 2010 +0100
+++ b/tools/libxl/libxl.h	Wed Aug 04 18:48:10 2010 +0100
@@ -22,8 +22,10 @@
 #include <xs.h>
 #include <sys/wait.h> /* for pid_t */
 
+#include <uuid/uuid.h>
+
 typedef struct {
-    uint8_t uuid[16];
+    uuid_t uuid;
     uint32_t domid;
     uint8_t running:1;
     uint8_t blocked:1;
@@ -50,7 +52,7 @@ typedef struct {
 } libxl_poolinfo;
 
 typedef struct {
-    uint8_t uuid[16];
+    uuid_t uuid;
     uint32_t domid;
 } libxl_vminfo;
 
@@ -93,7 +95,7 @@ typedef struct {
     bool oos;
     int ssidref;
     char *name;
-    uint8_t uuid[16];
+    uuid_t uuid;
     char **xsdata;
     char **platformdata;
     uint32_t poolid;
@@ -173,7 +175,7 @@ typedef enum {
 
 typedef struct {
     int domid;
-    uint8_t uuid[16]; /* this is use only with stubdom, and must be different
from the domain uuid */
+    uuid_t uuid; /* this is use only with stubdom, and must be different from
the domain uuid */
     char *dom_name;
     char *device_model;
     char *saved_state;
@@ -338,7 +340,7 @@ int libxl_domain_suspend(libxl_ctx *ctx,
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force);
-int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
libxl_domain_create_info *info, const char *name_suffix, uint8_t new_uuid[16]);
+int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
libxl_domain_create_info *info, const char *name_suffix, uuid_t new_uuid);
 
 int libxl_file_reference_map(libxl_ctx *ctx, libxl_file_reference *f);
 int libxl_file_reference_unmap(libxl_ctx *ctx, libxl_file_reference *f);
@@ -360,7 +362,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,
                          libxl_device_disk *disk,
                          uint32_t domid);
 
-char *libxl_uuid2string(libxl_ctx *ctx, const uint8_t uuid[16]);
+char *libxl_uuid2string(libxl_ctx *ctx, const uuid_t uuid);
   /* 0 means ERROR_ENOMEM, which we have logged */
 
 /* events handling */
diff -r 668f71224241 tools/libxl/xl.c
--- a/tools/libxl/xl.c	Mon Aug 02 16:58:50 2010 +0100
+++ b/tools/libxl/xl.c	Wed Aug 04 18:48:10 2010 +0100
@@ -69,8 +69,6 @@ int main(int argc, char **argv)
         exit(1);
     }
 
-    srand(time(0));
-
     cspec = cmdtable_lookup(cmd);
     if (cspec)
         ret = cspec->cmd_impl(argc, argv);
diff -r 668f71224241 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Aug 02 16:58:50 2010 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Aug 04 18:48:10 2010 +0100
@@ -255,19 +255,12 @@ static void init_build_info(libxl_domain
     }
 }
 
-static void random_uuid(uint8_t *uuid)
-{
-    int i;
-    for (i = 0; i < 16; i++)
-        uuid[i] = rand();
-}
-
 static void init_dm_info(libxl_device_model_info *dm_info,
         libxl_domain_create_info *c_info, libxl_domain_build_info *b_info)
 {
     memset(dm_info, ''\0'', sizeof(*dm_info));
 
-    random_uuid(&dm_info->uuid[0]);
+    uuid_generate(dm_info->uuid);
 
     dm_info->dom_name = c_info->name;
     dm_info->device_model = "qemu-dm";
@@ -294,7 +287,10 @@ static void init_dm_info(libxl_device_mo
 
 static void init_nic_info(libxl_device_nic *nic_info, int devnum)
 {
+    uuid_t seed;
+
     memset(nic_info, ''\0'', sizeof(*nic_info));
+    uuid_generate(seed);
 
     nic_info->backend_domid = 0;
     nic_info->domid = 0;
@@ -304,9 +300,9 @@ static void init_nic_info(libxl_device_n
     nic_info->mac[0] = 0x00;
     nic_info->mac[1] = 0x16;
     nic_info->mac[2] = 0x3e;
-    nic_info->mac[3] = 1 + (int) (0x7f * (rand() / (RAND_MAX + 1.0)));
-    nic_info->mac[4] = 1 + (int) (0xff * (rand() / (RAND_MAX + 1.0)));
-    nic_info->mac[5] = 1 + (int) (0xff * (rand() / (RAND_MAX + 1.0)));
+    nic_info->mac[3] = seed[0] & 0x7f;
+    nic_info->mac[4] = seed[1];
+    nic_info->mac[5] = seed[2];
     nic_info->ifname = NULL;
     nic_info->bridge = "xenbr0";
     CHK_ERRNO( asprintf(&nic_info->script, "%s/vif-bridge",
@@ -316,21 +312,24 @@ static void init_nic_info(libxl_device_n
 
 static void init_net2_info(libxl_device_net2 *net2_info, int devnum)
 {
+    uuid_t seed;
+
     memset(net2_info, ''\0'', sizeof(*net2_info));
+    uuid_generate(seed);
 
     net2_info->devid = devnum;
     net2_info->front_mac[0] = 0x00;
     net2_info->front_mac[1] = 0x16;
     net2_info->front_mac[2] = 0x3e;;
-    net2_info->front_mac[3] = 1 + (int) (0x7f * (rand() / (RAND_MAX +
1.0)));
-    net2_info->front_mac[4] = 1 + (int) (0xff * (rand() / (RAND_MAX +
1.0)));
-    net2_info->front_mac[5] = 1 + (int) (0xff * (rand() / (RAND_MAX +
1.0)));
+    net2_info->front_mac[3] = seed[0] & 0x7f;
+    net2_info->front_mac[4] = seed[1];
+    net2_info->front_mac[5] = seed[2];
     net2_info->back_mac[0] = 0x00;
     net2_info->back_mac[1] = 0x16;
     net2_info->back_mac[2] = 0x3e;
-    net2_info->back_mac[3] = 1 + (int) (0x7f * (rand() / (RAND_MAX + 1.0)));
-    net2_info->back_mac[4] = 1 + (int) (0xff * (rand() / (RAND_MAX + 1.0)));
-    net2_info->back_mac[5] = 1 + (int) (0xff * (rand() / (RAND_MAX + 1.0)));
+    net2_info->back_mac[3] = seed[3] & 0x7f;
+    net2_info->back_mac[4] = seed[4];
+    net2_info->back_mac[5] = seed[5];
     net2_info->back_trusted = 1;
     net2_info->filter_mac = 1;
     net2_info->max_bypasses = 5;
@@ -576,7 +575,7 @@ static void parse_config_data(const char
         c_info->name = strdup(buf);
     else
         c_info->name = "test";
-    random_uuid(&c_info->uuid[0]);
+    uuid_generate(c_info->uuid);
 
     if (!xlu_cfg_get_long(config, "oos", &l))
         c_info->oos = l;
@@ -1192,7 +1191,7 @@ static int preserve_domain(libxl_ctx *ct
         return 0;
     }
 
-    random_uuid(&new_uuid[0]);
+    uuid_generate(new_uuid);
 
     LOG("Preserving domain %d %s with suffix%s", domid,
d_config->c_info.name, stime);
     rc = libxl_domain_preserve(ctx, domid, &d_config->c_info, stime,
new_uuid);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Link to libuuid in xl et al and bring in the header file. Use libuuid to
> generate UUID's which are actually UU and not merely pseudo-random :)
> 
> As a side-effect I have also used libuuid to generate more random MAC
> addresses rather than keeping the old code and simply xoring getpid() in
> to the PRNG seed.
The MAC generation scheme in xend was awful -- it might be a good idea to take
this opportunity to fix things in libxl.

The best approach is to generate locally administered MAC addresses hence giving
us 46 bits of freedom rather than XenSource registered OUI addresses which have
just 24 bits -- collisions will be *much* less likely. Further, it's best
not to generate random addresses every time, but to derive the MAC address from
a good hash of the VM UUID and the NIC number so that they are deterministic.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/04/2010 07:19 PM, Ian Pratt wrote:
> The best approach is to generate locally administered MAC addresses hence
giving us 46 bits of freedom rather than XenSource registered OUI addresses
which have just 24 bits -- collisions will be *much* less likely. Further,
it''s best not to generate random addresses every time, but to derive
the MAC address from a good hash of the VM UUID and the NIC number so that they
are deterministic.
Yes!  I''ve been doing that manually (where my hash is
''+''), but its
irritating to keep doing over and over.

     J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 05/08/10 03:19, Ian Pratt wrote:
>> Link to libuuid in xl et al and bring in the header file. Use libuuid
to
>> generate UUID''s which are actually UU and not merely
pseudo-random :)
>>
>> As a side-effect I have also used libuuid to generate more random MAC
>> addresses rather than keeping the old code and simply xoring getpid()
in
>> to the PRNG seed.
>
> The MAC generation scheme in xend was awful -- it might be a good idea to
take this opportunity to fix things in libxl.
>
> The best approach is to generate locally administered MAC addresses hence
giving us 46 bits of freedom rather than XenSource registered OUI addresses
which have just 24 bits -- collisions will be *much* less likely. Further,
it''s best not to generate random addresses every time, but to derive
the MAC address from a good hash of the VM UUID and the NIC number so that they
are deterministic.
Adding some details here...

In general it would be a good idea to recopy already *existing* schemes 
(unless it can be proven to be the wrong thing to do) already available 
in XCP and XCI into libxl, instead of reinventing new square wheels like 
here. (although this square wheel is in xl not in libxl actually)

The MAC generation, as the one Ian mentioned, is already available in 
the XCI toolstack and in the XCP toolstack (the code there is a bit more 
scattered so i''ld recommend reading the XCI one).

-- 
Vincent

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 05 August 2010 11:19:18 Vincent Hanquez
wrote:
> On 05/08/10 03:19, Ian Pratt wrote:
> >> Link to libuuid in xl et al and bring in the header file. Use
libuuid to
> >> generate UUID''s which are actually UU and not merely
pseudo-random :)
> >>
> >> As a side-effect I have also used libuuid to generate more random
MAC
> >> addresses rather than keeping the old code and simply xoring
getpid() in
> >> to the PRNG seed.
> >
I want to mention that Linux and NetBSD''s uuid are different.
While on Linux you link against -luuid on NetBSD uuid is part of libc.
NetBSD implements DCE 1.1 
(http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt,
http://www.opengroup.org/onlinepubs/009629399/apdxa.htm).
Linux implements a different standard (I don''t know which one) where
the API is different.

Please have a look at tools/blktap2/include/blk_uuid.h
and tools/blktap2/drivers/Makefile
how to deal with both variants in a portable way.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 5 Aug 2010, Vincent Hanquez wrote:
> On 05/08/10 03:19, Ian Pratt wrote:
> >> Link to libuuid in xl et al and bring in the header file. Use
libuuid to
> >> generate UUID''s which are actually UU and not merely
pseudo-random :)
> >>
> >> As a side-effect I have also used libuuid to generate more random
MAC
> >> addresses rather than keeping the old code and simply xoring
getpid() in
> >> to the PRNG seed.
> >
> > The MAC generation scheme in xend was awful -- it might be a good idea
to take this opportunity to fix things in libxl.
> >
> > The best approach is to generate locally administered MAC addresses
hence giving us 46 bits of freedom rather than XenSource registered OUI
addresses which have just 24 bits -- collisions will be *much* less likely.
Further, it''s best not to generate random addresses every time, but to
derive the MAC address from a good hash of the VM UUID and the NIC number so
that they are deterministic.
> 
> Adding some details here...
> 
> In general it would be a good idea to recopy already *existing* schemes 
> (unless it can be proven to be the wrong thing to do) already available 
> in XCP and XCI into libxl, instead of reinventing new square wheels like 
> here. (although this square wheel is in xl not in libxl actually)
> 
> The MAC generation, as the one Ian mentioned, is already available in 
> the XCI toolstack and in the XCP toolstack (the code there is a bit more 
> scattered so i''ld recommend reading the XCI one).
> 
 
since you seem to know exactly where the code is, would you like to
submit a patch for that? ;)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 05/08/10 11:13, Christoph Egger wrote:
> I want to mention that Linux and NetBSD''s uuid are different.
>    
That''s one of the reason the uuid type as been just an array of bytes 
(up to this patch).
My reasoning was that anyone can use any libraries they want at the 
application-that-use-libxl level, and just need to feed the array of 
bytes with whatever has generated an uuid, be it a poor quality version 
or a good one.

-- 
Vincent

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 5 Aug 2010, Vincent Hanquez wrote:
> On 05/08/10 11:13, Christoph Egger wrote:
> > I want to mention that Linux and NetBSD''s uuid are different.
> >    
> That''s one of the reason the uuid type as been just an array of
bytes
> (up to this patch).
> My reasoning was that anyone can use any libraries they want at the 
> application-that-use-libxl level, and just need to feed the array of 
> bytes with whatever has generated an uuid, be it a poor quality version 
> or a good one.
 
I think it would be nice to provide a simple function in libxl that does
that for you, especially if we consider that it is easy to get it wrong.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Pratt writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid to generate
random UUID''s"):
> The best approach is to generate locally administered MAC addresses
> hence giving us 46 bits of freedom rather than XenSource registered
> OUI addresses which have just 24 bits -- collisions will be *much*
> less likely. Further, it''s best not to generate random addresses
> every time, but to derive the MAC address from a good hash of the VM
> UUID and the NIC number so that they are deterministic.
VM uuids are not stable in xend nor xl.  Perhaps xl should hash the VM
name, which is stable and supposedly unique.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 2010-08-09 at 11:51 +0100, Ian Jackson wrote:
> Ian Pratt writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid to
generate random UUID''s"):
> > The best approach is to generate locally administered MAC addresses
> > hence giving us 46 bits of freedom rather than XenSource registered
> > OUI addresses which have just 24 bits -- collisions will be *much*
> > less likely. Further, it''s best not to generate random
addresses
> > every time, but to derive the MAC address from a good hash of the VM
> > UUID and the NIC number so that they are deterministic.
> 
> VM uuids are not stable in xend nor xl.  Perhaps xl should hash the VM
> name, which is stable and supposedly unique.
But they can be made to be stable and I suppose this is the point here.
I think it makes more sense than unique names. In either case we would
need to bring in something like a SHA1 implementation I suppose. I''m
not
sure I see much point in this myself but if the consensus is there I can
implement it.

As for portability issues, I think Egger is right about blktap2 approach
being the way to go.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2010-08-05 at 03:27 +0100, Jeremy Fitzhardinge
wrote:
> On 08/04/2010 07:19 PM, Ian Pratt wrote:
> > The best approach is to generate locally administered MAC addresses
> hence giving us 46 bits of freedom rather than XenSource registered
> OUI addresses which have just 24 bits -- collisions will be *much*
> less likely. Further, it''s best not to generate random addresses
every
> time, but to derive the MAC address from a good hash of the VM UUID
> and the NIC number so that they are deterministic.
> 
> Yes!  I''ve been doing that manually (where my hash is
''+''), but its
> irritating to keep doing over and over.
Where I care about a stable MAC I use
	vif = [ ''mac=xx:xx:xx:xx:xx:xx'' ]
in my domain config file. AFAICT that is the only 100% reliable way to
get a stable MAC address since the other schemes all have some corner
case or other...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 10/08/10 11:44, Ian Campbell wrote:
> Where I care about a stable MAC I use
> 	vif = [ ''mac=xx:xx:xx:xx:xx:xx'' ]
> in my domain config file. AFAICT that is the only 100% reliable way to
> get a stable MAC address since the other schemes all have some corner
> case or other...
At the expense of the common error of having 2 vms with the same mac 
address because one copied the config file and forgot to change the mac 
address.

XCI and XCP doesn''t have any "corner cases or other" since
uuid uniquess
is enforced which means mac too (siding apart the unlikely hash collisions).

-- 
Vincent

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 10 Aug 2010, Vincent Hanquez wrote:
> On 10/08/10 11:44, Ian Campbell wrote:
> > Where I care about a stable MAC I use
> > 	vif = [ ''mac=xx:xx:xx:xx:xx:xx'' ]
> > in my domain config file. AFAICT that is the only 100% reliable way to
> > get a stable MAC address since the other schemes all have some corner
> > case or other...
> 
> At the expense of the common error of having 2 vms with the same mac 
> address because one copied the config file and forgot to change the mac 
> address.
> 
> XCI and XCP doesn''t have any "corner cases or other"
since uuid uniquess
> is enforced which means mac too (siding apart the unlikely hash
collisions).
 
I am still waiting for the patch :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Gianni Tedesco (3P) writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid to
generate random UUID''s"):
> On Mon, 2010-08-09 at 11:51 +0100, Ian Jackson wrote:
> > VM uuids are not stable in xend nor xl.  Perhaps xl should hash the VM
> > name, which is stable and supposedly unique.
> 
> But they can be made to be stable and I suppose this is the point here.
No, I don''t think VM uuids can be made stable in xl.  If for no other
reason than that localhost migration would be impossible.

I think the only way to have stable MAC addresses is to derive them
from the VM name, or for the user to explicitly write a MAC address in
the config file.

Users who do the latter will find things continue to work no matter
how we change the default scheme, and the default is already somewhat
broken, so perhaps we should indeed consider changing it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 2010-08-10 at 16:23 +0100, Ian Jackson wrote:
> Gianni Tedesco (3P) writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid
to generate random UUID''s"):
> > On Mon, 2010-08-09 at 11:51 +0100, Ian Jackson wrote:
> > > VM uuids are not stable in xend nor xl.  Perhaps xl should hash
the VM
> > > name, which is stable and supposedly unique.
> > 
> > But they can be made to be stable and I suppose this is the point
here.
> 
> No, I don''t think VM uuids can be made stable in xl.  If for no
other
> reason than that localhost migration would be impossible.
Oh right, good point.
> I think the only way to have stable MAC addresses is to derive them
> from the VM name, or for the user to explicitly write a MAC address in
> the config file.
VM''s can have the same name, so either ought to be an "domain
image" (or
something) UUID or just manually specify the mac.
> Users who do the latter will find things continue to work no matter
> how we change the default scheme, and the default is already somewhat
> broken, so perhaps we should indeed consider changing it.
I think in the absence of explicit instruction on what to set the MAC
to, picking it randomly would is a sensible approach. Whether it ought
to be in the local or global address namespace seems like the only
decision to make in this case.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > VM uuids are not stable in xend nor xl.  Perhaps xl should hash
the VM
> > > name, which is stable and supposedly unique.
> >
> > But they can be made to be stable and I suppose this is the point
here.
> 
> No, I don''t think VM uuids can be made stable in xl.  If for no
other
> reason than that localhost migration would be impossible.
Localhost migration is useful for testing but is not a normal mode of operation.
It''s fine to temporarily break the stability of UUIDs during the
localhost migration as long as it is cleaned up afterwards. The VMs will not
actually be running at the same time.
> I think the only way to have stable MAC addresses is to derive them
> from the VM name, or for the user to explicitly write a MAC address in
> the config file.
Deriving MAC addresses from the VM UUID is the best approach if the MAC
hasn''t been specified in the config file. Locally administered
addresses are the only sane thing to use if random addresses are being generated
-- there aren''t enough bits for AUI addresses to be generated randomly
without high probability of collision.

Ian
> Users who do the latter will find things continue to work no matter
> how we change the default scheme, and the default is already somewhat
> broken, so perhaps we should indeed consider changing it.
> 
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Gianni Tedesco writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid to
generate random UUID''s"):
> On Tue, 2010-08-10 at 16:23 +0100, Ian Jackson wrote:
> > I think the only way to have stable MAC addresses is to derive them
> > from the VM name, or for the user to explicitly write a MAC address in
> > the config file.
> 
> VM''s can have the same name, so either ought to be an "domain
image" (or
> something) UUID or just manually specify the mac.
No, simultaneously-running VMs in libxl cannot have the same name.
That this is not currently enforced is a bug.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/10/2010 03:44 AM, Ian Campbell wrote:
> On Thu, 2010-08-05 at 03:27 +0100, Jeremy Fitzhardinge wrote:
>> On 08/04/2010 07:19 PM, Ian Pratt wrote:
>>> The best approach is to generate locally administered MAC addresses
>> hence giving us 46 bits of freedom rather than XenSource registered
>> OUI addresses which have just 24 bits -- collisions will be *much*
>> less likely. Further, it''s best not to generate random
addresses every
>> time, but to derive the MAC address from a good hash of the VM UUID
>> and the NIC number so that they are deterministic.
>>
>> Yes!  I''ve been doing that manually (where my hash is
''+''), but its
>> irritating to keep doing over and over.
> Where I care about a stable MAC I use
> 	vif = [ ''mac=xx:xx:xx:xx:xx:xx'' ]
> in my domain config file. AFAICT that is the only 100% reliable way to
> get a stable MAC address since the other schemes all have some corner
> case or other...
I always manually set a uuid in the domain (well, uuid-gen), and I''d 
like the mac to be derived from that.

     J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/10/2010 08:23 AM, Ian Jackson wrote:
> Gianni Tedesco (3P) writes ("RE: [Xen-devel] [PATCH]: xl: use libuuid
to generate random UUID''s"):
>> On Mon, 2010-08-09 at 11:51 +0100, Ian Jackson wrote:
>>> VM uuids are not stable in xend nor xl.  Perhaps xl should hash the
VM
>>> name, which is stable and supposedly unique.
>> But they can be made to be stable and I suppose this is the point here.
> No, I don''t think VM uuids can be made stable in xl.  If for no
other
> reason than that localhost migration would be impossible.
Stable uuids are a primary requirement.  Localhost migration is a 
parlour trick which is useful for testing but little else.  Therefore, 
localhost migration should work around stable uuids rather than the 
other way around (failing if you''ve got a stable uuid defined would be
a
reasonable answer).

xl''s current behaviour of ignoring the config file uuid is an 
unequivocal bug.
> I think the only way to have stable MAC addresses is to derive them
> from the VM name, or for the user to explicitly write a MAC address in
> the config file.
Deriving from the vm name makes sense as a fallback if they haven''t 
specified a uuid.  But I think in that case it would make more sense to 
derive the uuid from the domain name, and then everything else from that 
uuid.
> Users who do the latter will find things continue to work no matter
> how we change the default scheme, and the default is already somewhat
> broken, so perhaps we should indeed consider changing it.
If the default uuid is random at the moment, then it should be pretty 
safe to change it to anything else.

     J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Jeremy Fitzhardinge writes ("Re: [Xen-devel] [PATCH]: xl: use libuuid to
generate random UUID''s"):
> Deriving from the vm name makes sense as a fallback if they
haven''t
> specified a uuid.  But I think in that case it would make more sense to 
> derive the uuid from the domain name, and then everything else from that 
> uuid.
That would satisfy me.  There should be a configurable seed for the
hash.
> If the default uuid is random at the moment, then it should be pretty 
> safe to change it to anything else.
Yes, provided it doesn''t cause clashes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel