[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] some questions about libvirt features and limitations



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 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]