11:59 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everyone,
I'm working on a open source project (http://www.hynesim.org) in which
we needed libvirt-like functionalities. As at the time, libvirt did not
support OpenVZ, and it did not support VirtualBox, we went and
implemented our own wrappers around Kvm/Qemu, VirtualBox and OpenVz
(Honeyd too, but our wrapper is such an ugly hack that it doesn't really
deserve mention).
Now that time has passed, we'd would like to stop duplicating efforts,
and use libvirt instead, and concentrate on more innovating
functionalities for Hynesim. Also our wrappers are terrible hacks, and
do a lot less error checking than libvirt :)
But before I can replace our wrappers with libvirt, we're missing some
functionalities (that I will propose a patch for if required), and there
are a few questions concerning libvirt I've not managed to find an
answer for, so I'd be very grateful if I could get some advice on them.
Here goes:
-------
Is it possible to add a device for any type of domain that would
correspond to a TAP device on the host, and would be seen as a regular
ethernet interface with a specific MAC address in the virtualized domain ?
The "raw" commands to achieve that in OpenVZ and Qemu, for example, are:
# kvm ... -net nic,macaddr=00:11:22:33:44:55 -net tap,ifname=tap0,script=no
# vzctl set 100 --netif_add eth0,00:11:22:33:44:55,tap0
Is that doable in every driver supported by libvirt ?
-------
Is the libvirtd daemon necessary for drivers other than Qemu ?
I've been using the openvz driver alone for some tests (by connecting to
"openvz:///system"), and yet I get warning messages:
# sudo ./hellolibvirt openvz:///system
Attempting to connect to hypervisor
libvir: Remote error : unable to connect to
'/var/run/libvirt/libvirt-sock': No such file or directory
libvir: warning : Failed to find the network: Is the daemon running ?
libvir: Remote error : unable to connect to
'/var/run/libvirt/libvirt-sock': No such file or directory
libvir: Remote error : unable to connect to
'/var/run/libvirt/libvirt-sock': No such file or directory
libvir: warning : Failed to find a node driver: Is the libvirtd daemon
running ?
Connected to hypervisor at "openvz:///system"
Hypervisor: "OpenVZ" version: 3.0.22
There are 0 active and 1 inactive domains
Inactive domains:
897
Disconnected from hypervisor
The libvirtd daemon is indeed not running, as I don't see why it should
be: I thought it was only useful for qemu guests. Am I right ?
What is the role of the daemon exactly ?
-------
Apparently the only way to start an OpenVZ domain is by specifying a
template. Only problem is, when the VE is stopped, and undefined, all
modifications are lost in the "private" file system of the VE (as it is
deleted). The way we circumvented this in Hynesim is by specifying the
- --private option to "vzctl create" instead of the --ostemplate one.
That way one can specify a dir that will be used directly as the
filesystem for the VE.
I was thinking maybe adding something along the lines of:
<filesystem type='directory'>
<source name='/path/to/ve/filesystem' />
<target dir='/'/>
</filesystem>
would do the trick. It looks simple enough to implement, so should I ?
-------
Is there support in libvirt of "cloning" (duplicating a VM disk
/filesystem) ?
-------
Someone mentioned a VirtualBox driver. I'm highly interested in this.
How is it going ? I'd be more than happy to beta test if required. Will
it work with both PUEL and OSE versions ? When will it be ready for
inclusion in libvirt ? How will you handle RDP access, as from what I
saw only VNC is supported in libvirt currently ?
-------
And last but not least, what are "node devices" ? The two pages about it
are blank in the documentation. Are they the host machine, or a device
of the host machine ?
-------
I think that's all.
Thank you for reading all this,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmtcBwACgkQgRp+dNkqn68FjQCcDhoy0YuhUM37iRc2cbyDdh1N
hE8AoKSAhoZJ7cSQ8zWSXr9XiOytTuLK
=LSi9
-----END PGP SIGNATURE-----
3:28 a.m.
Hi Florian,
Someone mentioned a VirtualBox driver. I'm highly interested in this.
How is it going ? I'd be more than happy to beta test if required. Will
it work with both PUEL and OSE versions ? When will it be ready for
inclusion in libvirt ? How will you handle RDP access, as from what I
saw only VNC is supported in libvirt currently ?
I am currently working on Virtualbox driver and they are still in nascent
stage of development.
Yes they will support both the versions cause they depend on the Common Main
VirtualBox API.
About inclusion in libvirt, that will depend on the libvirt community, as I
would submit the patches but only on review/ack by all they will pass on
upstream.
Not reached the stage of deciding on RDP/VNC yet but any help in it will be
appreciated.
Regards,
-pritesh
5:05 a.m.
On Wed, Mar 04, 2009 at 10:28:56AM +0100, Pritesh Kothari wrote:
Hi Florian,
>
> Someone mentioned a VirtualBox driver. I'm highly interested in this.
> How is it going ? I'd be more than happy to beta test if required. Will
> it work with both PUEL and OSE versions ? When will it be ready for
> inclusion in libvirt ? How will you handle RDP access, as from what I
> saw only VNC is supported in libvirt currently ?
I am currently working on Virtualbox driver and they are still in nascent
stage of development.
Yes they will support both the versions cause they depend on the Common Main
VirtualBox API.
About inclusion in libvirt, that will depend on the libvirt community, as I
would submit the patches but only on review/ack by all they will pass on
upstream.
We'd very much like to see VirtualBox suported as a driver in libvirt
because its a pretty popular open source virt technology and there have
been quite a few feature requests from users for it to be included.
Not reached the stage of deciding on RDP/VNC yet but any help in it
will be
appreciated.
I see no problem in supporting RDP as an option for VirtualBox. We
already have two possible <graphics> tags
<graphics type='sdl' display=":0.0"
xauth="/root/.Xauthority"/>
And
<graphics type='vnc' listen='0.0.0.0' port='5901'
autoport='yes'/>
So we can easily add another option for RDP, which I'd guess would
be very similar to the VNC options, since its another client/server
network based system
<graphics type='rdp' listen='0.0.0.0' port='5901'
autoport='yes'/>
Regards,
Daniel
--
|: 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 :|
6:55 a.m.
Hi Daniel,
We'd very much like to see VirtualBox suported as a driver in libvirt
because its a pretty popular open source virt technology and there have
been quite a few feature requests from users for it to be included.
I have an very rough snapshot working just for creating/destroying/listing
machines. Is there any way I can find out that if i am in the right direction
with it? maybe i can send the patch directly to someone for review (the code
is very basic and i don't directly want to submit it to list yet)
Regards,
-pritesh
6:59 a.m.
On Fri, Mar 06, 2009 at 01:55:56PM +0100, Pritesh Kothari wrote:
Hi Daniel,
>
> We'd very much like to see VirtualBox suported as a driver in libvirt
> because its a pretty popular open source virt technology and there have
> been quite a few feature requests from users for it to be included.
I have an very rough snapshot working just for creating/destroying/listing
machines. Is there any way I can find out that if i am in the right direction
with it? maybe i can send the patch directly to someone for review (the code
is very basic and i don't directly want to submit it to list yet)
Certainly feel free to send it to the list for review whenever you have
something interesting you want feedback on. There's no requirement for
it to be finished / fully functional, looking at work in progress code
can help spot problems early
Regards,
Daniel
--
|: 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 :|
9:27 a.m.
New subject: [libvirt] VirtualBox support to libvirt
Hi All,
I have attached a patch which when applied on the HEAD would
allow virtualbox support in libvirt.
The steps to apply patch are:
tar -zxvf vbox-patch.tar.gz
git-apply vbox-patch
The patch works very well with the VirtualBox OSE svn HEAD and
is supposed to support VirtualBox 2.2 onwards both editions.
If anyone wants to run it on current VirtualBox OSE svn HEAD
(2.1.51_OSE r17375) then the steps are as follows:
1)After compiling and installing VBox OSE you need to copy the
file out/linux.amd64/debug/bin/VBoxXPCOMC.so to the install
directory.
2) export VBOX_APP_HOME=<install dir>
3) run virsh to connect to virtualbox as below:
virsh -c vbox:///session
Regards,
Pritesh
6:44 a.m.
New subject: [libvirt] VirtualBox support to libvirt
On Fri, Mar 06, 2009 at 04:27:53PM +0100, Pritesh Kothari wrote:
Hi All,
I have attached a patch which when applied on the HEAD would
allow virtualbox support in libvirt.
The steps to apply patch are:
tar -zxvf vbox-patch.tar.gz
git-apply vbox-patch
Minor point for next time - it'd make it a little quicker to review
if could just attach the plain vbox.patch file directly to the mail.
If it hits the maximum attachment size allowed by mailman, one of
us can easily approve the mail, or just split it into sections.
The patch works very well with the VirtualBox OSE svn HEAD and
is supposed to support VirtualBox 2.2 onwards both editions.
If anyone wants to run it on current VirtualBox OSE svn HEAD
(2.1.51_OSE r17375) then the steps are as follows:
1)After compiling and installing VBox OSE you need to copy the
file out/linux.amd64/debug/bin/VBoxXPCOMC.so to the install
directory.
2) export VBOX_APP_HOME=<install dir>
3) run virsh to connect to virtualbox as below:
virsh -c vbox:///session
I'm not too familiar with virtualbox - am I right in thinking that each
user can run their own set of virtual machines, independantly of others
If so, then your choice of URLs vbox:///session fits perfectly :-)
I've had a quick look at the patch & it basically looks to be developing
well. I will just list a few pretty minor suggestions or questions here
for now, rather than doing a full inline patch review.
- There's a few places using of malloc/realloc/free, rather than
VIR_ALLOC/REALLOC_N/FREE.
- There's a couple of places doing sizeof(s_aSyms) / sizeof(s_aSyms[0])
In util.h, there is a convenient macro ARRAY_CARDINAILITY(s_aSyms)
that lets you do this
- The general integration bits you've done in Makefile.am, src/libvirt.c
configure.ac and src/virterror.c all look correct
- Does the src/vbox/VBoxCAPI_v2_2.h file need to be present in the
source tree ? I would have expected the VirtualBox-devel RPm (or
equivalent to be providing the header file definitions for the
API interface, but perhaps I'm mis-understanding the purpose of
this file
- I'm curious as to why you're changing the UUID format in nsIDtoChar,
switching the positions of bytes in the UUID ?
+ uuidstrdst[0] = uuidstrsrc[6];
+ uuidstrdst[1] = uuidstrsrc[7];
+ uuidstrdst[2] = uuidstrsrc[4];
+ uuidstrdst[3] = uuidstrsrc[5];
+ uuidstrdst[4] = uuidstrsrc[2];
+ uuidstrdst[5] = uuidstrsrc[3];
+ uuidstrdst[6] = uuidstrsrc[0];
+ uuidstrdst[7] = uuidstrsrc[1];
- When creating virDomainPtr objects, rather than directly allocating
them, and then setting the id, uuid, and name fields, we have a
helper method in src/datatypes.h you can use:
virDomainPtr virGetDomain(virConnectPtr conn,
const char *name,
const unsigned char *uuid);
This avoids the need to worry about the fine details of the ref
counting & caching associated with these objects. So generally
shouldn't directly access the conn->domains hash table from driver
code.
- The vboxGetDomainGetOSType() method shouldn't actually return the
name of the guest operating system. This is one of the badly named
libvirt methods. What it is actually intended for is to give the
name of the guest operating system hypervisor ABI. Since VirtualBox
is a fully-virtualized hypervisor, it should always just return 'hvm'
for the OS type.
- The vboxCapsInit() should also pass 'hvm' as the OS type field,
rather than 'exe'which is for container based virt like OpenVZ.
Also in that method, "sizeof(int) == 4 ? 32 : 8" - i think that
8 should probably be 64 :-)
- In the vboxGetDomainDefineXML(), there's a couple of places accessing
def->features bits - you could use the VIR_DOMAIN_FEATURE_* enums
for those.
- Since VirtualBox is a local machine driver, there's probably no need
to register virNetworkDriver, virStorageDriver, virDeviceMonitor driver
structs with libvirt. Just let the generic shared implementation
activate - we re-use this shared network & storage impl across all our
drivers at this time.
Then again if the VirtualBox API provides explicit APIs for managing
LVM, SCSI, iSCSI storage and NAT based networks, then perhaps it
would be worth having an impl of these drivers for VirtualBox. I'd
still just leave them out for now though, until the main VirtualBox
hypervisor APIs are more developed.
All in all, it looks like you've got a pretty good understanding of
what to do with VirtualBox for libvirt driver support. Look forward
to seeing future versions of the patch...
Regards,
Daniel
--
|: 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 :|
8:31 a.m.
New subject: [libvirt] VirtualBox support to libvirt
Hi Daniel,
Minor point for next time - it'd make it a little quicker to
review
if could just attach the plain vbox.patch file directly to the mail.
If it hits the maximum attachment size allowed by mailman, one of
us can easily approve the mail, or just split it into sections.
Sorry, would this from next time.
I'm not too familiar with virtualbox - am I right in thinking that
each
user can run their own set of virtual machines, independantly of others
If so, then your choice of URLs vbox:///session fits perfectly
yes, in virtualbox each user can run their own machines.
I've had a quick look at the patch & it basically looks to be
developing
well. I will just list a few pretty minor suggestions or questions here
for now, rather than doing a full inline patch review.
Thanks
- There's a few places using of malloc/realloc/free, rather
than
VIR_ALLOC/REALLOC_N/FREE.
- There's a couple of places doing sizeof(s_aSyms) / sizeof(s_aSyms[0])
In util.h, there is a convenient macro ARRAY_CARDINAILITY(s_aSyms)
that lets you do this
Will take care of above two points.
- Does the src/vbox/VBoxCAPI_v2_2.h file need to be present in the
source tree ? I would have expected the VirtualBox-devel RPm (or
equivalent to be providing the header file definitions for the
API interface, but perhaps I'm mis-understanding the purpose of
this file
The reason is that this way the libvirt implementation is self contained and
VirtualBox support can be enabled by default. The second reason is that the
VirtualBox API tends to change in incompatible ways so future libvirt patches
will be able to deal with multiple versions of VirtualBox and therefore also
have multiple header files.
- I'm curious as to why you're changing the UUID format in
nsIDtoChar,
switching the positions of bytes in the UUID ?
+ uuidstrdst[0] = uuidstrsrc[6];
+ uuidstrdst[1] = uuidstrsrc[7];
+ uuidstrdst[2] = uuidstrsrc[4];
+ uuidstrdst[3] = uuidstrsrc[5];
+ uuidstrdst[4] = uuidstrsrc[2];
+ uuidstrdst[5] = uuidstrsrc[3];
+ uuidstrdst[6] = uuidstrsrc[0];
+ uuidstrdst[7] = uuidstrsrc[1];
In vbox nsID is implemented as:
struct nsID {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
PRUint8 m3[8];
};
while in libvirt it is implemented as unsigned char uuid[16];
On little endian machines this creates byte swaps as shown above
and thus the workaround.
(The http://www.ietf.org/rfc/rfc4122.txt , section 4.1.2 shows the layout and
byte order)
- When creating virDomainPtr objects, rather than directly
allocating
them, and then setting the id, uuid, and name fields, we have a
helper method in src/datatypes.h you can use:
virDomainPtr virGetDomain(virConnectPtr conn,
const char *name,
const unsigned char *uuid);
This avoids the need to worry about the fine details of the ref
counting & caching associated with these objects. So generally
shouldn't directly access the conn->domains hash table from driver
code.
Will take care of this.
- The vboxGetDomainGetOSType() method shouldn't actually return
the
name of the guest operating system. This is one of the badly named
libvirt methods. What it is actually intended for is to give the
name of the guest operating system hypervisor ABI. Since VirtualBox
is a fully-virtualized hypervisor, it should always just return 'hvm'
for the OS type.
- The vboxCapsInit() should also pass 'hvm' as the OS type field,
rather than 'exe'which is for container based virt like OpenVZ.
Also in that method, "sizeof(int) == 4 ? 32 : 8" - i think that
8 should probably be 64 :-)
- In the vboxGetDomainDefineXML(), there's a couple of places accessing
def->features bits - you could use the VIR_DOMAIN_FEATURE_* enums
for those.
Will take care of this.
- Since VirtualBox is a local machine driver, there's probably
no need
to register virNetworkDriver, virStorageDriver, virDeviceMonitor driver
structs with libvirt. Just let the generic shared implementation
activate - we re-use this shared network & storage impl across all our
drivers at this time.
Then again if the VirtualBox API provides explicit APIs for managing
LVM, SCSI, iSCSI storage and NAT based networks, then perhaps it
would be worth having an impl of these drivers for VirtualBox. I'd
still just leave them out for now though, until the main VirtualBox
hypervisor APIs are more developed.
for time being i will remove these.
All in all, it looks like you've got a pretty good understanding
of
what to do with VirtualBox for libvirt driver support. Look forward
to seeing future versions of the patch...
Thanks for such verbose review.
and yes, it is nice to work with the libvirt community, will post more when I
get things working.
Regards,
-pritesh
4:25 a.m.
On Tue, Mar 03, 2009 at 06:59:56PM +0100, Florian Vichot wrote:
Is it possible to add a device for any type of domain that would
correspond to a TAP device on the host, and would be seen as a regular
ethernet interface with a specific MAC address in the virtualized domain ?
The "raw" commands to achieve that in OpenVZ and Qemu, for example, are:
# kvm ... -net nic,macaddr=00:11:22:33:44:55 -net tap,ifname=tap0,script=no
# vzctl set 100 --netif_add eth0,00:11:22:33:44:55,tap0
Is that doable in every driver supported by libvirt ?
I'm not sure - it depends what you're doing with the TAP device on the
host side of things ?
We have two common network configs, 'shared physical device' where
the guest TAP device (or equivalent) is bridged to a physiucal interface,
and 'virtual network' where the guest TAP is connected to an isolated
bridge and forwarded with masquarading, or isolated device where the
guest TAP is connected to a bridge, but has no LAN access at all. These
are supported in all drivers. There's a couple more network options
but those aren't so widely supported
http://libvirt.org/formatdomain.html#elementsNICS
http://wiki.libvirt.org/page/Networking
Is the libvirtd daemon necessary for drivers other than Qemu ?
I've been using the openvz driver alone for some tests (by connecting to
"openvz:///system"), and yet I get warning messages:
# sudo ./hellolibvirt openvz:///system
Attempting to connect to hypervisor
libvir: Remote error : unable to connect to
'/var/run/libvirt/libvirt-sock': No such file or directory
libvir: warning : Failed to find the network: Is the daemon running ?
libvir: Remote error : unable to connect to
'/var/run/libvirt/libvirt-sock': No such file or directory
libvir: Remote error : unable to connect to
'/var/run/libvirt/libvirt-sock': No such file or directory
libvir: warning : Failed to find a node driver: Is the libvirtd daemon
running ?
Connected to hypervisor at "openvz:///system"
Hypervisor: "OpenVZ" version: 3.0.22
There are 0 active and 1 inactive domains
Inactive domains:
897
Disconnected from hypervisor
The libvirtd daemon is indeed not running, as I don't see why it should
be: I thought it was only useful for qemu guests. Am I right ?
What is the role of the daemon exactly ?
It provides the implementation for various parts of the API, specificaly
the network driver, the storage driver, node device driver. Some of the
hypervisor drivers also live in the daemon (QEMU & LXC). So it should
be running at all times.
It can also be configured to allow secure remote access with TLS/SSL
and SASL authenticaiton.
Apparently the only way to start an OpenVZ domain is by specifying a
template. Only problem is, when the VE is stopped, and undefined, all
modifications are lost in the "private" file system of the VE (as it is
deleted). The way we circumvented this in Hynesim is by specifying the
- --private option to "vzctl create" instead of the --ostemplate one.
That way one can specify a dir that will be used directly as the
filesystem for the VE.
I was thinking maybe adding something along the lines of:
<filesystem type='directory'>
<source name='/path/to/ve/filesystem' />
<target dir='/'/>
</filesystem>
would do the trick. It looks simple enough to implement, so should I ?
Yes, seems like a good idea. We already support <filesystem
type='directory'>
for the LXC container driver, so it makes perfect sense to support it for
OpenVZ too if its practical.
Is there support in libvirt of "cloning" (duplicating a VM
disk
/filesystem) ?
Not at this time, but it is on the todo list.
And last but not least, what are "node devices" ? The two
pages about it
are blank in the documentation. Are they the host machine, or a device
of the host machine ?
They are APIs to let you query information about all devices present on
the host node. eg, find out about PCI devices, USB devices, block devices,
network interfaces, etc, etc. If you know the 'HAL' software, then it is
basically doing the same thing.
Daniel
--
|: 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 :|
9:11 a.m.
I'm not sure - it depends what you're doing with the TAP
device on the
host side of things ?
The project I'm working on is an information system simulator. So I need
virtual machines and virtual networks. I plan to use libvirt to provide
the virtual machines, but even though I know libvirt provides virtual
network facilities, the ones we developed are more adequate to what we
need. So I need a way to "bridge" the network frames coming from the
virtual machines into our "virtual networks". The way we do that using
our current setup is by "sniffing" all traffic from TAP interface (that
each corresponds to an "ethX" interface inside a guest) and injecting
those frames inside our "virtual networks" to have those frames routed
where necessary.
So what I need is a TAP for each ethernet interface in each guest, and
that's it. No bridge, no NAT. Just a one-to-one correspondence of guest
"ethX" interfaces to host TAP interfaces.
It seems to be what libvirt provides, but it always comes with a bridge.
Is there a way to get the TAP without the bridge ?
It provides the implementation for various parts of the API,
specificaly
the network driver, the storage driver, node device driver. Some of the
hypervisor drivers also live in the daemon (QEMU & LXC). So it should
be running at all times.
It can also be configured to allow secure remote access with TLS/SSL
and SASL authenticaiton.
Thank you for the clarification. I will start the daemon then :).
Yes, seems like a good idea. We already support <filesystem
type='directory'>
for the LXC container driver, so it makes perfect sense to support it for
OpenVZ too if its practical.
Ok. Then I'll do that, and send a patch to the mailing list separately.
> Is there support in libvirt of "cloning" (duplicating a
VM disk
> /filesystem) ?
Not at this time, but it is on the todo list.
Too bad. I'll probably keep my ugly code for that until the API are
added in libvirt, then I'll port what I have to libvirt.
They are APIs to let you query information about all devices present
on
the host node. eg, find out about PCI devices, USB devices, block devices,
network interfaces, etc, etc. If you know the 'HAL' software, then it is
basically doing the same thing.
Thank you for the explanation.
Florian.
PS: Sorry for the duplicate original email.
6:09 a.m.
On Wed, Mar 04, 2009 at 04:11:54PM +0100, Florian Vichot wrote:
>I'm not sure - it depends what you're doing with the TAP
device on the
>host side of things ?
The project I'm working on is an information system simulator. So I need
virtual machines and virtual networks. I plan to use libvirt to provide
the virtual machines, but even though I know libvirt provides virtual
network facilities, the ones we developed are more adequate to what we
need. So I need a way to "bridge" the network frames coming from the
virtual machines into our "virtual networks". The way we do that using
our current setup is by "sniffing" all traffic from TAP interface (that
each corresponds to an "ethX" interface inside a guest) and injecting
those frames inside our "virtual networks" to have those frames routed
where necessary.
So what I need is a TAP for each ethernet interface in each guest, and
that's it. No bridge, no NAT. Just a one-to-one correspondence of guest
"ethX" interfaces to host TAP interfaces.
It seems to be what libvirt provides, but it always comes with a bridge.
Is there a way to get the TAP without the bridge ?
I think you'd have to rely on the generic script capability, eg
<interface type='ethernet'>
<script path="/some/file"/>
</interface>
With that, QEMU / Xen will create the TAP device (or equivalent) and
then run the script to configure it. You'd just provide a custom script
todo whatever magic you desire with the TAP device.
This is only supported in our Xen and QEMU drivers at this time, though
it probably wouldn't be hard to implement it for OpenVZ / LXC / UML too.
Regards,
Daniel
--
|: 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 :|
5736
days inactive
5743
days old
10 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Florian Vichot -
Pritesh Kothari