RE: [Xen-tools] QEMU, HVM guests, and vif.

["Scrowston, Jo" <Jo.Scrowston@xxxxxxxxxxxx>]

My mistake, the MAC dictated by the config file is applied to the eth device in DomU not the tun device in Dom0.

So problem2 goes away, but I still need to find a way of adding the correct tun to the correct bridge.

 

 

 

 

 

---

From: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-tools-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scrowston, Jo
Sent: 18 September 2006 09:25
To: xen-tools@xxxxxxxxxxxxxxxxxxxx
Subject: [Xen-tools] QEMU, HVM guests, and vif.

 

Hope this is the right forum for asking this question.

 

I am finding that my HVM guests are using tun interfaces in the Dom0 bridge instead of vif interfaces, looks like this is a QEMU thing. The vif interfaces are generated at startup but not used. There are 2 major problems with this.

 

1)       All of my guests are on 2 networks with 2 NICS. Although the correct vif interfaces are being put in the correct bridge (for what it’s worth), the tun interfaces all go in the first bridge and are not named in a way that makes them identifiable for moving.

2)       If the vif interface is not used I cannot dictate MAC address from ‘vmname.hvm’ and therefore cannot allocate IP address from DHCP reservations.

 

   In the following examples 2 guest OS’s exist (vmid 10 and 11).

   In the first case Dom0 and both vm’s work on net1 but vm’s do not work on net2. This is default behaviour.

   In the 2^nd case some changes have been made and all vm’s work on all networks.

 

   [root@XenHost02 ~]# brctl show

   bridge name     bridge id               STP enabled     interfaces

   xenbr0          8000.3264131ec979       no              peth0

                                                           tun0

                                                           tun1

                                                           tun2

                                                           tun3

                                                           vif0.0

                                                           vif10.0

                                                           vif11.0

   xenbr1          8000.d6a5a5f280b3       no              peth1

                                                          vif0.1

                                                          vif10.1

                                                          vif11.1

 

   [root@XenHost02 ~]# brctl show

   bridge name     bridge id               STP enabled     interfaces

   xenbr0          8000.3264131ec979       no              peth0

                                                           tun0

                                                           tun2

                                                           vif0.0

   xenbr1          8000.d6a5a5f280b3       no              peth1

                                                          tun1

                                                          tun3

                                                          vif0.1

 

Note that I removed the vm vifs in case2, this is because they don’t do anything anyway, frustrating because they’re in the correct bridges. I could write a cludgy script to automate this, but identification of tun interfaces with 10+ vm’s is going to be a problem and I still will be unable to allocate MAC-address which for me is a big issue.

 

Is this default behaviour for QEMU? It’s going to cause problems for HVM guests in the future.

 

Thanks for listening.

 

 

This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential.  Any dissemination, copying or distribution of this message or any attachments is strictly prohibited.

If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer.

Messages sent to and from Quadriga may be monitored.

Quadriga cannot guarantee any message delivery method is secure or error-free.  Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission.

You should carry out your own virus checks before opening any attachment.

Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

This e-mail is the property of Quadriga Worldwide Ltd, intended for the addressee only and confidential.  Any dissemination, copying or distribution of this message or any attachments is strictly prohibited.

If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer.

Messages sent to and from Quadriga may be monitored.

Quadriga cannot guarantee any message delivery method is secure or error-free.  Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission.

You should carry out your own virus checks before opening any attachment.

Any views or opinions presented are solely those of the author and do not necessarily represent those of Quadriga.

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