| Message ID | 1381810677-4369-1-git-send-email-qiudayu@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
Am 15.10.2013 06:17, schrieb Mike Qiu: > Changelog to v1: > Find remainder of macaddr->a[5] by modulo 256, > otherwise it may be overflow by add index++. > > The default mac address is 52:54:00:12:34:56 + index, this will > cause problem that when we boot up more than one guest with all > mac addresses unset by default, assume that each guest has one > nic. In this situation, all the guest's nic has the same mac address. > > This patch is to solve this bug. > > Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com> > --- > net/net.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/net/net.c b/net/net.c > index c330c9a..9e72764 100644 > --- a/net/net.c > +++ b/net/net.c > @@ -21,6 +21,8 @@ > * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > * THE SOFTWARE. > */ > +#include <time.h> > + > #include "config-host.h" > > #include "net/net.h" > @@ -147,12 +149,13 @@ void qemu_macaddr_default_if_unset(MACAddr *macaddr) > > if (memcmp(macaddr, &zero, sizeof(zero)) != 0) > return; > + srand((unsigned)time(NULL)); > macaddr->a[0] = 0x52; > macaddr->a[1] = 0x54; > macaddr->a[2] = 0x00; > - macaddr->a[3] = 0x12; > - macaddr->a[4] = 0x34; > - macaddr->a[5] = 0x56 + index++; > + macaddr->a[3] = rand() % 256; > + macaddr->a[4] = rand() % 256; > + macaddr->a[5] = (rand() % 256 + index++) % 256; > } > > /** There is no overflow which must be handled because a[5] is an uint8_t value, so the assignment automatically limits the range to 0...255. Is it reasonable to get a random mac address in your guest? I don't think so. It would no longer be possible to connect to a guest using ssh, restart that guest and connect again with ssh. If you start more than one guest, you simply have to decide which mac address you want and tell it on the command line. Stefan
On 10/15/2013 01:07 PM, Stefan Weil wrote: > Am 15.10.2013 06:17, schrieb Mike Qiu: >> Changelog to v1: >> Find remainder of macaddr->a[5] by modulo 256, >> otherwise it may be overflow by add index++. >> >> The default mac address is 52:54:00:12:34:56 + index, this will >> cause problem that when we boot up more than one guest with all >> mac addresses unset by default, assume that each guest has one >> nic. In this situation, all the guest's nic has the same mac address. >> >> This patch is to solve this bug. >> >> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com> >> --- >> net/net.c | 9 ++++++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/net/net.c b/net/net.c >> index c330c9a..9e72764 100644 >> --- a/net/net.c >> +++ b/net/net.c >> @@ -21,6 +21,8 @@ >> * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN >> * THE SOFTWARE. >> */ >> +#include <time.h> >> + >> #include "config-host.h" >> >> #include "net/net.h" >> @@ -147,12 +149,13 @@ void qemu_macaddr_default_if_unset(MACAddr *macaddr) >> >> if (memcmp(macaddr, &zero, sizeof(zero)) != 0) >> return; >> + srand((unsigned)time(NULL)); >> macaddr->a[0] = 0x52; >> macaddr->a[1] = 0x54; >> macaddr->a[2] = 0x00; >> - macaddr->a[3] = 0x12; >> - macaddr->a[4] = 0x34; >> - macaddr->a[5] = 0x56 + index++; >> + macaddr->a[3] = rand() % 256; >> + macaddr->a[4] = rand() % 256; >> + macaddr->a[5] = (rand() % 256 + index++) % 256; >> } >> >> /** > There is no overflow which must be handled because a[5] is an uint8_t > value, so the assignment automatically limits the range to 0...255. OK, you are right, but I think we'd better to ensure this, even though a[5] is an uint8_t. > Is it reasonable to get a random mac address in your guest? I don't > think so. It would no longer be possible to connect to a guest using > ssh, restart that guest and connect again with ssh. Why not? I have do the experiment, after reboot, the mac is not changed. and the ip address always the same. And can be login to the guest after reboot. > > If you start more than one guest, you simply have to decide which mac > address you want and tell it on the command line. Yes, mostly we should do this, but users sometimes not do this, so this interface should cover this situation. Thank Mike > > Stefan > > > >
Am 15.10.2013 07:57, schrieb mike: > On 10/15/2013 01:07 PM, Stefan Weil wrote: >> Am 15.10.2013 06:17, schrieb Mike Qiu: >>> Changelog to v1: >>> Find remainder of macaddr->a[5] by modulo 256, >>> otherwise it may be overflow by add index++. >>> >>> The default mac address is 52:54:00:12:34:56 + index, this will >>> cause problem that when we boot up more than one guest with all >>> mac addresses unset by default, assume that each guest has one >>> nic. In this situation, all the guest's nic has the same mac address. >>> >>> This patch is to solve this bug. >>> >>> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com> >>> --- >>> net/net.c | 9 ++++++--- >>> 1 file changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/net/net.c b/net/net.c >>> index c330c9a..9e72764 100644 >>> --- a/net/net.c >>> +++ b/net/net.c >>> @@ -21,6 +21,8 @@ >>> * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >>> DEALINGS IN >>> * THE SOFTWARE. >>> */ >>> +#include <time.h> >>> + >>> #include "config-host.h" >>> #include "net/net.h" >>> @@ -147,12 +149,13 @@ void qemu_macaddr_default_if_unset(MACAddr >>> *macaddr) >>> if (memcmp(macaddr, &zero, sizeof(zero)) != 0) >>> return; >>> + srand((unsigned)time(NULL)); >>> macaddr->a[0] = 0x52; >>> macaddr->a[1] = 0x54; >>> macaddr->a[2] = 0x00; >>> - macaddr->a[3] = 0x12; >>> - macaddr->a[4] = 0x34; >>> - macaddr->a[5] = 0x56 + index++; >>> + macaddr->a[3] = rand() % 256; >>> + macaddr->a[4] = rand() % 256; >>> + macaddr->a[5] = (rand() % 256 + index++) % 256; >>> } >>> /** >> There is no overflow which must be handled because a[5] is an uint8_t >> value, so the assignment automatically limits the range to 0...255. > OK, you are right, but I think we'd better to ensure this, > even though a[5] is an uint8_t. >> Is it reasonable to get a random mac address in your guest? I don't >> think so. It would no longer be possible to connect to a guest using >> ssh, restart that guest and connect again with ssh. > Why not? I have do the experiment, after reboot, the mac is not changed. > and the ip address always the same. > > And can be login to the guest after reboot. "restart" means terminate QEMU and start it again.
On 10/15/2013 02:05 PM, Stefan Weil wrote: > Am 15.10.2013 07:57, schrieb mike: >> On 10/15/2013 01:07 PM, Stefan Weil wrote: >>> Am 15.10.2013 06:17, schrieb Mike Qiu: >>>> Changelog to v1: >>>> Find remainder of macaddr->a[5] by modulo 256, >>>> otherwise it may be overflow by add index++. >>>> >>>> The default mac address is 52:54:00:12:34:56 + index, this will >>>> cause problem that when we boot up more than one guest with all >>>> mac addresses unset by default, assume that each guest has one >>>> nic. In this situation, all the guest's nic has the same mac address. >>>> >>>> This patch is to solve this bug. >>>> >>>> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com> >>>> --- >>>> net/net.c | 9 ++++++--- >>>> 1 file changed, 6 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/net/net.c b/net/net.c >>>> index c330c9a..9e72764 100644 >>>> --- a/net/net.c >>>> +++ b/net/net.c >>>> @@ -21,6 +21,8 @@ >>>> * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >>>> DEALINGS IN >>>> * THE SOFTWARE. >>>> */ >>>> +#include <time.h> >>>> + >>>> #include "config-host.h" >>>> #include "net/net.h" >>>> @@ -147,12 +149,13 @@ void qemu_macaddr_default_if_unset(MACAddr >>>> *macaddr) >>>> if (memcmp(macaddr, &zero, sizeof(zero)) != 0) >>>> return; >>>> + srand((unsigned)time(NULL)); >>>> macaddr->a[0] = 0x52; >>>> macaddr->a[1] = 0x54; >>>> macaddr->a[2] = 0x00; >>>> - macaddr->a[3] = 0x12; >>>> - macaddr->a[4] = 0x34; >>>> - macaddr->a[5] = 0x56 + index++; >>>> + macaddr->a[3] = rand() % 256; >>>> + macaddr->a[4] = rand() % 256; >>>> + macaddr->a[5] = (rand() % 256 + index++) % 256; >>>> } >>>> /** >>> There is no overflow which must be handled because a[5] is an uint8_t >>> value, so the assignment automatically limits the range to 0...255. >> OK, you are right, but I think we'd better to ensure this, >> even though a[5] is an uint8_t. >>> Is it reasonable to get a random mac address in your guest? I don't >>> think so. It would no longer be possible to connect to a guest using >>> ssh, restart that guest and connect again with ssh. >> Why not? I have do the experiment, after reboot, the mac is not changed. >> and the ip address always the same. >> >> And can be login to the guest after reboot. > "restart" means terminate QEMU and start it again. OK, qemu support the mac address unset right ? So it may be a joke if just can start only one VM with mac address unset :). In your case, also can use monitor to get the mac address, simply 'info network' :) Then you can do as if you set the mac address. Thanks Mike > > >
On 10/14/2013 11:07 PM, Stefan Weil wrote: > > Is it reasonable to get a random mac address in your guest? I don't > think so. It would no longer be possible to connect to a guest using > ssh, restart that guest and connect again with ssh. Agreed - libvirt ALWAYS passes a MAC to qemu, even if the user did not specify a MAC to libvirt, precisely because the MAC must be reproducible rather than random to avoid changing the guest ABI. I don't think this patch is needed - it's up to management to use qemu correctly.
On 10/15/2013 08:36 PM, Eric Blake wrote: > On 10/14/2013 11:07 PM, Stefan Weil wrote: >> Is it reasonable to get a random mac address in your guest? I don't >> think so. It would no longer be possible to connect to a guest using >> ssh, restart that guest and connect again with ssh. > Agreed - libvirt ALWAYS passes a MAC to qemu, even if the user did not > specify a MAC to libvirt, precisely because the MAC must be reproducible > rather than random to avoid changing the guest ABI. I don't think this > patch is needed - it's up to management to use qemu correctly. Yes, you are right in this condition. But qemu support Mac address unset. Also we can get the ip address through a lot of different ways, like use monitor to get the mac and then get the ip. So we can login use ssh. But as you mentioned, this patch is not needed, I don't agree with you. First, this patch just fix the Potential issue of this feature. Now libvirt maybe can't triggered this issue, who can promise in future will not. The second is, qemu not only be used by libvirt, lots of developers like to use the command line to boot up the guest. And in the future, we are not sure about other program will use qemu. The third is, when one feature has a issue in qemu, no matter when it is been triggered, should we not fix it? Mike Thanks
On Tue, Oct 15, 2013 at 09:33:06PM +0800, mike wrote: > On 10/15/2013 08:36 PM, Eric Blake wrote: > >On 10/14/2013 11:07 PM, Stefan Weil wrote: > >>Is it reasonable to get a random mac address in your guest? I don't > >>think so. It would no longer be possible to connect to a guest using > >>ssh, restart that guest and connect again with ssh. > >Agreed - libvirt ALWAYS passes a MAC to qemu, even if the user did not > >specify a MAC to libvirt, precisely because the MAC must be reproducible > >rather than random to avoid changing the guest ABI. I don't think this > >patch is needed - it's up to management to use qemu correctly. > Yes, you are right in this condition. But qemu support Mac address unset. > Also we can get the ip address through a lot of different ways, like use > monitor to get the mac and then get the ip. So we can login use ssh. > > But as you mentioned, this patch is not needed, I don't agree with you. > > First, this patch just fix the Potential issue of this feature. Now libvirt > maybe can't triggered this issue, who can promise in future will not. > > The second is, qemu not only be used by libvirt, lots of developers like > to use the command line to boot up the guest. And in the future, we > are not sure about other program will use qemu. > > The third is, when one feature has a issue in qemu, > no matter when it is been triggered, should we not fix it? NACK I'm not going to merge this patch: If you terminate QEMU and launch it again the NIC gets a different MAC address. Some guest operating systems are sensitive to this - under many Linux distros the network interfaces names change due to the MAC address change. As a result firewall configuration will break and other services may fail to start because they cannot find the interface. If you have multiple guests or want control over the MAC address, set it explicitly using -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. Stefan
On 10/17/2013 08:30 PM, Stefan Hajnoczi wrote: > On Tue, Oct 15, 2013 at 09:33:06PM +0800, mike wrote: >> On 10/15/2013 08:36 PM, Eric Blake wrote: >>> On 10/14/2013 11:07 PM, Stefan Weil wrote: >>>> Is it reasonable to get a random mac address in your guest? I don't >>>> think so. It would no longer be possible to connect to a guest using >>>> ssh, restart that guest and connect again with ssh. >>> Agreed - libvirt ALWAYS passes a MAC to qemu, even if the user did not >>> specify a MAC to libvirt, precisely because the MAC must be reproducible >>> rather than random to avoid changing the guest ABI. I don't think this >>> patch is needed - it's up to management to use qemu correctly. >> Yes, you are right in this condition. But qemu support Mac address unset. >> Also we can get the ip address through a lot of different ways, like use >> monitor to get the mac and then get the ip. So we can login use ssh. >> >> But as you mentioned, this patch is not needed, I don't agree with you. >> >> First, this patch just fix the Potential issue of this feature. Now libvirt >> maybe can't triggered this issue, who can promise in future will not. >> >> The second is, qemu not only be used by libvirt, lots of developers like >> to use the command line to boot up the guest. And in the future, we >> are not sure about other program will use qemu. >> >> The third is, when one feature has a issue in qemu, >> no matter when it is been triggered, should we not fix it? > NACK > > I'm not going to merge this patch: > > If you terminate QEMU and launch it again the NIC gets a different MAC > address. Some guest operating systems are sensitive to this - under For these users must use -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. I think no body will boot up the guest, which sensitive to this, without mac address. Actually, people use the command line without mac address, mean they mainly don't care about mac address, so give them random mac address is reasonable I think. In my opinion, if we fix this, for qemu side no any issue, we both support mac address set or unset correctly. What am I confuse is, *qemu supports mac address unset, why we force users must set the address when more than one guests*? This is unreasonable. > many Linux distros the network interfaces names change due to the MAC > address change. As a result firewall configuration will break and other > services may fail to start because they cannot find the interface. Agree, so this mac address should set in qemu command line as libvirt does :) > If you have multiple guests or want control over the MAC address, set it > explicitly using -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. Currently, especially for developers, people mainly use qemu command line directly, and as qemu supports mac address unset, they may try the simplest command line to boot up lots of guests, they will confuse about why all this guest use the same mac address. Thanks Mike > Stefan > > >
On Fri, Oct 18, 2013 at 10:54:13AM +0800, mike wrote: > >NACK > > > >I'm not going to merge this patch: > > > >If you terminate QEMU and launch it again the NIC gets a different MAC > >address. Some guest operating systems are sensitive to this - under > For these users must use -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. > I think no body will boot up the guest, which sensitive to this, > without mac address. > > Actually, people use the command line without mac address, mean they mainly > don't care about mac address, so give them random mac address is reasonable > I think. > > In my opinion, if we fix this, for qemu side no any issue, we both support > mac address set or unset correctly. > > What am I confuse is, *qemu supports mac address unset, why we force > users must set the address when more than one guests*? > This is unreasonable. > > >many Linux distros the network interfaces names change due to the MAC > >address change. As a result firewall configuration will break and other > >services may fail to start because they cannot find the interface. > Agree, so this mac address should set in qemu command line as > libvirt does :) > >If you have multiple guests or want control over the MAC address, set it > >explicitly using -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. > Currently, especially for developers, people mainly use qemu > command line directly, and as qemu supports mac address > unset, they may try the simplest command line to boot up > lots of guests, they will confuse about why all this guest use > the same mac address. Your argument is weak: *you* want to avoid specifying the MAC address so in exchange you want to *break* existing configurations and force other people to start specifying a MAC address. This doesn't improve anything, it will just annoy users and cause bug reports. Sorry that there isn't a solution that satisfies everyone, you'll have to add a MAC address to your command-line. Stefan
On 10/18/2013 05:00 PM, Stefan Hajnoczi wrote: > On Fri, Oct 18, 2013 at 10:54:13AM +0800, mike wrote: >>> NACK >>> >>> I'm not going to merge this patch: >>> >>> If you terminate QEMU and launch it again the NIC gets a different MAC >>> address. Some guest operating systems are sensitive to this - under >> For these users must use -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. >> I think no body will boot up the guest, which sensitive to this, >> without mac address. >> >> Actually, people use the command line without mac address, mean they mainly >> don't care about mac address, so give them random mac address is reasonable >> I think. >> >> In my opinion, if we fix this, for qemu side no any issue, we both support >> mac address set or unset correctly. >> >> What am I confuse is, *qemu supports mac address unset, why we force >> users must set the address when more than one guests*? >> This is unreasonable. >> >>> many Linux distros the network interfaces names change due to the MAC >>> address change. As a result firewall configuration will break and other >>> services may fail to start because they cannot find the interface. >> Agree, so this mac address should set in qemu command line as >> libvirt does :) >>> If you have multiple guests or want control over the MAC address, set it >>> explicitly using -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. >> Currently, especially for developers, people mainly use qemu >> command line directly, and as qemu supports mac address >> unset, they may try the simplest command line to boot up >> lots of guests, they will confuse about why all this guest use >> the same mac address. > Your argument is weak: *you* want to avoid specifying the MAC address so > in exchange you want to *break* existing configurations and force other > people to start specifying a MAC address. OK, I do not want to break the existing configurations. I'm fine if you do not want to merge this patch. But I think this should be an issue of qemu, and need to do something on it, so I make this patch. Can we try other solutions to solve this issue? (if you agree this should be an issue) Also this potential issue can happens if the user set the same mac address with more than one guest on one host. Can we avoid this ? Thanks Mike > This doesn't improve anything, it will just annoy users and cause bug > reports. > > Sorry that there isn't a solution that satisfies everyone, you'll have > to add a MAC address to your command-line. > > Stefan > > >
On Fri, Oct 18, 2013 at 11:44 AM, mike <qiudayu@linux.vnet.ibm.com> wrote: > On 10/18/2013 05:00 PM, Stefan Hajnoczi wrote: > > On Fri, Oct 18, 2013 at 10:54:13AM +0800, mike wrote: > > NACK > > I'm not going to merge this patch: > > If you terminate QEMU and launch it again the NIC gets a different MAC > address. Some guest operating systems are sensitive to this - under > > For these users must use -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. > I think no body will boot up the guest, which sensitive to this, > without mac address. > > Actually, people use the command line without mac address, mean they mainly > don't care about mac address, so give them random mac address is reasonable > I think. > > In my opinion, if we fix this, for qemu side no any issue, we both support > mac address set or unset correctly. > > What am I confuse is, *qemu supports mac address unset, why we force > users must set the address when more than one guests*? > This is unreasonable. > > many Linux distros the network interfaces names change due to the MAC > address change. As a result firewall configuration will break and other > services may fail to start because they cannot find the interface. > > Agree, so this mac address should set in qemu command line as > libvirt does :) > > If you have multiple guests or want control over the MAC address, set it > explicitly using -device <nic-model>,mac=XX:XX:XX:XX:XX:XX. > > Currently, especially for developers, people mainly use qemu > command line directly, and as qemu supports mac address > unset, they may try the simplest command line to boot up > lots of guests, they will confuse about why all this guest use > the same mac address. > > Your argument is weak: *you* want to avoid specifying the MAC address so > in exchange you want to *break* existing configurations and force other > people to start specifying a MAC address. > > OK, I do not want to break the existing configurations. > > I'm fine if you do not want to merge this patch. > > But I think this should be an issue of qemu, and need to > do something on it, so I make this patch. > > Can we try other solutions to solve this issue? > (if you agree this should be an issue) Options: 1. Set mac= on the command-line 2. Save the QEMU command-line in a script so the guest can be launched without remembering the details 3. Use -writeconfig/-readconfig to save the command-line to file and restore it Option 2 or 3 are more convenient than Option 1. Does that help? Finally, if random MACs are desirable for your particular use case, create a wrapper script that does something like: #!/bin/bash exec qemu-system-x86_64 "$@" -set device.mynic.mac=04:ab:cd:$((RANDOM % 256)):$((RANDOM % 256)):$((RANDOM % 256)) > Also this potential issue can happens if the user set the same mac address > with more than one guest on one host. > > Can we avoid this ? The same situation is possible on a physical LAN. MAC or IP collisions are configuration issues. I don't see collisions as a QEMU issue. Stefan
diff --git a/net/net.c b/net/net.c index c330c9a..9e72764 100644 --- a/net/net.c +++ b/net/net.c @@ -21,6 +21,8 @@ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. */ +#include <time.h> + #include "config-host.h" #include "net/net.h" @@ -147,12 +149,13 @@ void qemu_macaddr_default_if_unset(MACAddr *macaddr) if (memcmp(macaddr, &zero, sizeof(zero)) != 0) return; + srand((unsigned)time(NULL)); macaddr->a[0] = 0x52; macaddr->a[1] = 0x54; macaddr->a[2] = 0x00; - macaddr->a[3] = 0x12; - macaddr->a[4] = 0x34; - macaddr->a[5] = 0x56 + index++; + macaddr->a[3] = rand() % 256; + macaddr->a[4] = rand() % 256; + macaddr->a[5] = (rand() % 256 + index++) % 256; } /**
Changelog to v1: Find remainder of macaddr->a[5] by modulo 256, otherwise it may be overflow by add index++. The default mac address is 52:54:00:12:34:56 + index, this will cause problem that when we boot up more than one guest with all mac addresses unset by default, assume that each guest has one nic. In this situation, all the guest's nic has the same mac address. This patch is to solve this bug. Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com> --- net/net.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)