[libvirt] VirtualBox libvirt support sample XML file
Daniel P. Berrange
berrange at redhat.com
Thu Apr 16 15:41:58 UTC 2009
On Thu, Apr 16, 2009 at 01:42:11PM +0200, Pritesh Kothari wrote:
> Hi Daniel,
> > > <!--INTERNAL NETWORK -->
> > > <interface type='network'>
> > > <source network='int_net'/>
> > > <model type='am79c970a'/>
> > > </interface>
> > >
> > > <!-- HOST ONLY NETWORK -->
> > > <interface type='ethernet'>
> > > <source dev='vboxnet0'/>
> > > <mac address='78:16:3e:4d:c7:9e'/>
> > > <model type='82543gc'/>
> > > </interface>
> > The Bridge & NAT mappings you've defined here seem to make
> > good sense.
> > I'm not so sure about the INTERNAL and HOST ONLY modes
> > though.
> > With the <interface type='network'> configuration, the
> > source network is expected to refer to a network visible
> > and managed via the virNetwork* APIs.
> > In QEMU / Xen drivers, we have a generic network driver
> > impl that uses a bridge device, dnsmasq & iptables to
> > allow guests to talk to each other, optionaly talk to the
> > host, and then optionally have NAT connectivity to the
> > outside world. This is the src/network_driver.c impl of
> > the virNetwork* APIs.
> > Conceptually the virNetwork APIs & their functionality ought
> > to map nicely onto the both the INTERNAL and HOST ONLY
> > networks modes virtual box has.
> > The HOST ONLY mode, would map to a config without a
> > <forward> tag (so guests & host can talk to each other).
> > The INTERNAL mode, wouldmap toa config without an
> > <ip> tag (so guests can talk to each other, but not host)
> > What I'm not clear on is where / how VirtualBox configures its
> > HOST ONLY and INTERNAL networks ? Does it have APIs for managing
> > these 2 configs as objects in their own right ? Or are they managed
> > implicilty via the VM config. The RPC stub code you posted earlier
> > does not appear to have any APIs for directly configuring the
> > HOST ONLY / INTERNAL network configs, independantly of the VM config
> > I might be mis-reading something though..
> > I'm inclined to suggest that virtual box driver should provide its own
> > impl of the virNetwork internal driver API, in order to allow direct
> > managemnet of the HOST ONLY & INTENRAL networks. Then for VM NICs,
> > both those would be done via a <interface type='network'> element.
> I am not sure if "Host only" and "internal" network deserves a full
> implementation of the virNetwork internal driver API because they are not
> exposed as separate objects, instead each network card can be individually
> specified as having "Host only" or "Internal" network configuration and
> VirtualBox handles rest, so all i need is a way to specify which network type
> to use and an IPAddr if possible and thus I had map-ed them as above.
> Currently the only way I can think of simplifying it is adding "Host Only"
> and "Internal" to the XML parsing and using it.
Looking at the API and admin UI, VirtualBox does provide for mnagement
of Host only networks as an explicit concept, allowing configuration
of the IP details, and DHCP, eg these commands
VBoxManage hostonlyif ipconfig <name>
--ip<ipv4> [--netmask<ipv4> (def: 255.255.255.0)] |
--ipv6<ipv6> [--netmasklengthv6<length> (def: 64)]]
VBoxManage dhcpserver add|modify --netname <network_name> |
[--enable | --disable]
VBoxManage dhcpserver remove --netname <network_name> |
The Linux impl only appears to allow for a single hostonlyif at this
time, but the Windows impl looks like it can do multiple.
IMHO, this maps pretty well onto the virNetwork driver API, albeit
with some restricts. eg, you would not be allowed to delete the
'internal only' network, it'd simply always be present. Likewise
the Linux impl would only allow for a single hostonlyif until it
gains the functionality for create/delete
The problem with adding extra 'host only' and 'internal' options to
the domain XML format for <interface type='xxx'/>, is that this
creates a different approach to configuration for Xen/QEMU vs
VirtualBox drivers in libvirt. virt-manager for example, is focused
on providing guest connectivity via type='bridge' or type='network'.
Your VirtualBox driver already does type=bridge fine, so if we implement
the hostonly & internal network modes via the virNetwork APIs, then
the rest of the virt-manager networking UI will work nicely with
the VirtualBox driver.
|: 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 :|
More information about the libvir-list