- Users - libvirt List Archives

[libvirt-users] SASL GSSAPI error "Key table entry not found"
by Adam Gray 01 Jul '10

01 Jul '10

My server and client are running Ubuntu Lucid, libvirt-bin 0.7.5-5ubuntu27, qemu-kvm-0.12.3+noroms-0ubuntu9 and I'm using virt-viewer-0.0.3-6ubuntu7.xul19 or virt-manager-0.8.2-2ubuntu8 to connect. I configured SASL2 to use GSSAPI for libvirt following the instructions in the libvirt docs, created a keytab with libvirt/my.fully.qualified.domain(a)MY-REALM.COM (has a dash fwiw) and pointed SASL2 and libvirt at /etc/krb5.keytab (changing the location of that doesn't seem to work for my version, but that's no biggie). So I sit on my client and run this: virsh -c qemu+tcp://my.fully.qualified.domain/system And I get this message on the client: error: authentication failed error: failed to connect to the hypervisor And this on the server logs: 16:37:35.278: error : remoteDispatchAuthSaslStart:3135 : sasl start failed -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table entry not found)) For fun, I ran kdestroy and tried again and got this: error: Failed to start SASL negotiation: -1 (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_1000' not found)) error: failed to connect to the hypervisor So at least the client seems to be presenting my ticket properly, but the server is either looking for the wrong keytab entry or I can't read very well. -adam

4 7

[libvirt-users] non-root user "virConnectOpen() faile" in libvirt-0.3
by Shenglan Wang 01 Jul '10

01 Jul '10

*Hello,* * * *My environment is "Xen3.1 in Fedora8" with "libvirt0.3 & python2.5". When I ran the following * *commands as a non-root user "nimbus":* $python >>> import libvirt >>> libvirt.open("xen:///") --------- Console --------- [nimbus@localhost-120 ~]$ python Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> libvirt.open("xen:///") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/libvirt.py", line 123, in open if ret is None:raise libvirtError('virConnectOpen() failed') libvirt.libvirtError: virConnectOpen() failed >>> *I encountered the error "virConnectOpen() failed". if I changed the user into root, it worked well. * *But I hava to use the non-root account "nimbus". I looked into the problem on the net, in order * *that non-root user could use libvirt as root user, someone suggested that I should modify the libvirt * *configuration file "/etc/libvirt/libvirtd.conf", but they didn't point out what field should be changed.* * * *I am puzzled about that problem. I have already changed the sudo file and the xen configuration * *file "/etc/xen/xend-config.sxp", which doesn't work at all. Could someome give me any tips? * --------- "/etc/xen/xend-config.sxp" --------- (xend-http-server yes) (xend-unix-server yes) (network-script network-bridge) * * *Thanks in advance!* * * *Cheers,* * * *Shenglan Wang*

1 0

[libvirt-users] how to match the ID of a LUN in a storage pool with the GUID on the target server
by Tom Georgoulias 30 Jun '10

30 Jun '10

I've configured a libvirt storage pool using an iscsi target from a Sun 7310 storage appliance and am using the LUNs in this target as volumes for my KVM guests. The setup is very similar to what Daniel covered in a recent blog posting: http://berrange.com/posts/2010/05/05/provisioning-kvm-virtual-machines-on-i… It works great, but I can't figure out how to match the volume names & path IQNs within the storage pool to the GUIDs on the target. For example, here's what I see when I use the vol-info command: # virsh vol-list kvm-target Name Path ----------------------------------------- 6.0.0.0 /dev/disk/by-path/ip-X.X.X.X:3260-iscsi-iqn.1986-03.com.sun:02:<snipped>-lun-0 6.0.0.1 /dev/disk/by-path/ip-X.X.X.X:3260-iscsi-iqn.1986-03.com.sun:02:<snipped>-lun-1 The IQN matches the targets IQN, but when I browse the LUNs from the storage system I do not see a way to determine which of them is *-lun-0 and which is *-lun-1, I only see a GUID and an alias name that I created. Is there any way to get that info (or something else that will do the job) from a virsh command? Thanks in advance for any help. Tom

2 5

[libvirt-users] Are memoryPeek and blockPeek still not supported?
by steven765＠yahoo.com 30 Jun '10

30 Jun '10

Hi, I just tried x=dom.blockPeek('disk',5,0,buf,0) and it returns AtrributeError: 'module' object has no attribute 'virDomainBlockPeek' I found this bug submission from early 09: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=492683 Is that still correct are they not implemented. Or did i screw up the command? Thanks, Steve

1 0

[libvirt-users] Better error codes when stopping a VM that is already stopped
by Guido Winkelmann 30 Jun '10

30 Jun '10

Hi, Sometimes when stopping a virtual domain using virDomainDestroy(), I come across a domain that is already stopped. (For example when someone already stopped the domain manually using virsh or because the guest OS issued a shutdown.) This is a special case that I absolutely need to catch and handle. Unfortunately, when this happens, and I call virGetLastError() afterwards, I always just get the error code VIR_ERR_OPERATION_INVALID, which doesn't look very precise to me... Two questions about this: Is the domain not running at that moment the only possible condition that can trigger this particular error code when calling virDomainDestroy()? Can't we have a more obvious/precise error code in that case, like VIR_ERR_DOMAIN_NOT_RUNNING or something like that? Guido Winkelmann

4 6

[libvirt-users] FYI: a short guide to libvirt & network filtering iptables/ebtables use
by Daniel P. Berrange 30 Jun '10

30 Jun '10

I just wrote this to assist some Red Hat folks understanding what libvirt does with iptables, and thought it is useful info for the whole libvirt community. When I have time I'll adjust this content so that it can fit into the website in relevant pages/places. Firewall / network filtering in libvirt ======================================= There are three pieces of libvirt functionality which do network filtering of some type. At a high level they are: - The virtual network driver. This provides a isolated bridge device (ie no physical NICs enslaved). Guest TAP devices are attached to this bridge. Guests can talk to each other & the host, and optionally the wider world. - The QEMU driver MAC filtering This provides a generic filtering of MAC addresses to prevent the guest spoofing its MAC address. This is mostly obsoleted by the next item, so won't be discussed further. - The network filter driver This provides fully configurable, arbitrary network filtering of traffic on guest NICs. Generic rulesets are defined at the host level to control traffic in some manner. Rules sets are then associated with individual NICs of a guest. While not as expressive as directly using iptables/ebtables, this can still do nearly everything you would want to on a guest NIC filter. The virtual network driver ========================== The typical configuration for guests is to use bridging of the physical NIC on the host to connect the guest directly to the LAN. In RHEL6 there is also the possibility of using macvtap/sr-iov and VEPA connectivity. None of this stuff plays nicely with wireless NICs, since they will typically silently drop any traffic with a MAC address that doesn't match that of the physical NIC. Thus the virtual network driver in libvirt was invented. This takes the form of an isolated bridge device (ie one with no physical NICs enslaved). The TAP devices associated with the guest NICs are attached to the bridge device. This immediately allows guests on a single host to talk to each other and to the host OS (modulo host IPtables rules). libvirt then uses iptables to control what further connectivity is available. There are three configurations possible for a virtual network at time of writing - isolated: all off-node traffic is completely blocked - nat: outbound traffic to the LAN is allowed, but MASQUERADED - forward: outbound traffic to the LAN is allowed The latter 'forward' case requires the virtual network be on a separate sub-net from the main LAN, and that the LAN admin has configured routing for this subnet. In the future we intend to add support for IP subnetting and/or proxy-arp. This allows for the virtual network to use the same subnet as the main LAN & should avoid need for the LAN admin to configure special routing. Libvirt will optionally also provide DHCP services to the virtual network using DNSMASQ. In all cases, we need to allow DNS/DHCP queries to the host OS. Since we can't predict whether the host firewall setup is already allowing this, we insert 4 rules into the head of the INPUT chain target prot opt in out source destination ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Note we have restricted our rules to just the bridge associated with the virutal network, to avoid opening undesirable holes in the host firewall wrt the LAN/WAN. The next rules depend on the type of connectivity allowed, and go in the main FORWARD chain: type=isolated ------------- Allow traffic between guests. Deny inbound. Deny outbound. target prot opt in out source destination ACCEPT all -- virbr1 virbr1 0.0.0.0/0 0.0.0.0/0 REJECT all -- * virbr1 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- virbr1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable type=nat -------- Allow inbound related to an established connection. Allow outbound, but only from our expected subnet. Allow traffic between guests. Deny all other inbound. Deny all other outbound. target prot opt in out source destination ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable type=routed ----------- Allow inbound, but only to our expected subnet. Allow outbound, but only from our expected subnet. Allow traffic between guests. Deny all other inbound. Deny all other outbound. target prot opt in out source destination ACCEPT all -- * virbr2 0.0.0.0/0 192.168.124.0/24 ACCEPT all -- virbr2 * 192.168.124.0/24 0.0.0.0/0 ACCEPT all -- virbr2 virbr2 0.0.0.0/0 0.0.0.0/0 REJECT all -- * virbr2 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- virbr2 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Finally, with type=nat, there is also an entry in the POSTROUTING chain to apply masquerading target prot opt in out source destination MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24 The network filter driver ========================= This driver provides a fully configurable network filtering capability that leverages ebtables, iptables and ip6tables. This was written by the libvirt guys at IBM and although its XML schema is defined by libvirt, the conceptual model is closely aligned with the DMTF CIM schema for network filtering http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf The filters are managed in libvirt as a top level, standalone object. This allows the filters to then be referenced by any libvirt object that requires their functionality, instead tieing them only to use by guest NICs. In the current implementation, filters can be associated with individual guest NICs via the libvirt domain XML format. In the future we might allow filters to be associated with the virtual network objects. Further we're expecting to define a new 'virtual switch' object to remove the complexity of configuring bridge/sriov/vepa networking modes. This make also end up making use of network filters. There are a new set of virsh commands for managing network filters virsh nwfilter-define define or update a network filter from an XML file virsh nwfilter-undefine undefine a network filter virsh nwfilter-dumpxml network filter information in XML virsh nwfilter-list list network filters virsh nwfilter-edit edit XML configuration for a network filter There are equivalently named C APIs for each of these commands. As with all objects libvirt manages, network filters are configured using an XML format. At a high level the format looks like this: <filter name='no-spamming' chain='XXXX'> <uuid>d217f2d7-5a04-0e01-8b98-ec2743436b74</uuid> <rule ...> .... </rule> <filterref filter='XXXX'/> </filter> Every filter has a name and UUID which serve as unique identifiers. A filter can have zero-or-more <rule> elements which are used to actually define network controls. Filters can be arranged into a DAG, so zero-or-more <filterref/> elements are also allowed. Cycles in the graph are not allowed. The <rule> element is where all the interesting stuff happens. It has three attributes, an action, a traffic direction and an optional priority. eg <rule action='drop' direction='out' priority='500'> Within the rule there are a wide variety of elements allowed, which do protocol specific matching. Supported protocols currently include 'mac', 'arp', 'rarp', 'ip', 'ipv6', 'tcp/ip', 'icmp/ip', 'igmp/ip', 'udp/ip', 'udplite/ip' 'esp/ip', 'ah/ip', 'sctp/ip', 'tcp/ipv6', 'icmp/ipv6', 'igmp/ipv6', 'udp/ipv6', 'udplite/ipv6', 'esp/ipv6', 'ah/ipv6', 'sctp/ipv6'. Each protocol defines what is valid inside the <rule> element, the general pattern though is <protocol match='yes|no' attribute1='value1' attribute2='value2'/> so, eg a TCP protocol, matching ports 0-1023 would be expressed as: <tcp match='yes' srcportstart='0' srcportend='1023'/> Attributes can included references to variables defined by the object using the rule. So the guest XML format allows each NIC to have a MAC address and IP address defined. These are made available to filters via the variables $IP and $MAC. So to define a filter the prevents IP address spoofing we can simply match on source IP address != $IP <filter name='no-ip-spoofing' chain='ipv4'> <rule action='drop' direction='out'> <ip match='no' srcipaddr='$IP' /> </rule> </filter> I'm not going to go into details on all the other protocol matches you can do, because it'll take far too much space. You can read about the options here http://libvirt.org/formatnwfilter.html#nwfelemsRulesProto Out of the box in RHEL6/Fedora rawhide, libvirt ships with a set of default useful rules # virsh nwfilter-list UUID Name ---------------------------------------------------------------- 15b1ab2b-b1ac-1be2-ed49-2042caba4abb allow-arp 6c51a466-8d14-6d11-46b0-68b1a883d00f allow-dhcp 7517ad6c-bd90-37c8-26c9-4eabcb69848d allow-dhcp-server 3d38b406-7cf0-8335-f5ff-4b9add35f288 allow-incoming-ipv4 5ff06320-9228-2899-3db0-e32554933415 allow-ipv4 db0b1767-d62b-269b-ea96-0cc8b451144e clean-traffic f88f1932-debf-4aa1-9fbe-f10d3aa4bc95 no-arp-spoofing 772f112d-52e4-700c-0250-e178a3d91a7a no-ip-multicast 7ee20370-8106-765d-f7ff-8a60d5aaf30b no-ip-spoofing d5d3c490-c2eb-68b1-24fc-3ee362fc8af3 no-mac-broadcast fb57c546-76dc-a372-513f-e8179011b48a no-mac-spoofing dba10ea7-446d-76de-346f-335bd99c1d05 no-other-l2-traffic f5c78134-9da4-0c60-a9f0-fb37bc21ac1f no-other-rarp-traffic 7637e405-4ccf-42ac-5b41-14f8d03d8cf3 qemu-announce-self 9aed52e7-f0f3-343e-fe5c-7dcb27b594e5 qemu-announce-self-rarp Most of these are just building blocks. The interesting one here is 'clean-traffic'. This pulls together all the building blocks into one filter that you can then associate with a guest NIC. This stops the most common bad things a guest might try, IP spoofing, arp spoofing and MAC spoofing. To look at the rules for any of these just do virsh nwfilter-dumpxml FILTERNAME|UUID They are all stored in /etc/libvirt/nwfilter, but don't edit files there directly. Use 'virsh nwfilter-define' to update them. This ensures the guests have their iptables/ebtables rules recreated. To associate the clean-trafffic filter with a guest, edit the guest XML config and change the <interface> element to include a <filterref> and also specify the whitelisted <ip addres/> the guest is allowed to use <interface type='bridge'> <mac address='52:54:00:56:44:32'/> <source bridge='br1'/> <ip address='10.33.8.131'/> <target dev='vnet0'/> <model type='virtio'/> <filterref filter='clean-traffic'/> </interface> If no <ip address> is included, the network filter driver will activate its 'learning mode'. This uses libpcap to snoop on network traffic the guest sends and attempts to identify the first IP address it uses. It then locks traffic to this address. Obviously this isn't entirely secure, but it does offer some protection against the guest being trojaned once up & running. In the future we intend to enhance the learning mode so that it looks for DHCPOFFERS from a trusted DHCP server and only allows the offered IP address to be used. Now, how is all this implemented... The network filter driver uses a combination of ebtables, iptables and ip6tables, depending on which protocols are referenced in a filter. The out of the box 'clean-traffic' filter rules only require use of ebtables. If you want to do matching at tcp/udp/etc protocols (eg to add a new filter 'no-email-spamming' to block port 25), then iptables will also be used. The driver attempts to keep its rules separate from those that the host admin might already have configured. So the first thing it does with ebtables, is to add two hooks in POSTROUTING & PREROUTING chains, to redirect traffic to custom chains. These hooks match on the TAP device name of the guest NIC, so they should not interact badly with any administrator defined rules Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0 Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0 To keep things managable & easy to follow, the driver will then create further sub-chains for each protocol then it needs to match against: Bridge chain: libvirt-I-vnet0, entries: 5, policy: ACCEPT -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arp -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p ARP -j O-vnet0-arp -p 0x8035 -j O-vnet0-rarp -j DROP Finally, come the actual implementation of the filters. These example is showing the 'clean-traffic' filter implementation. I'm not going to explain what this is doing now :-) Bridge chain: I-vnet0-ipv4, entries: 2, policy: ACCEPT -s ! 52:54:0:56:44:32 -j DROP -p IPv4 --ip-src ! 10.33.8.131 -j DROP Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT -j ACCEPT Bridge chain: I-vnet0-arp, entries: 6, policy: ACCEPT -s ! 52:54:0:56:44:32 -j DROP -p ARP --arp-mac-src ! 52:54:0:56:44:32 -j DROP -p ARP --arp-ip-src ! 10.33.8.131 -j DROP -p ARP --arp-op Request -j ACCEPT -p ARP --arp-op Reply -j ACCEPT -j DROP Bridge chain: O-vnet0-arp, entries: 5, policy: ACCEPT -p ARP --arp-op Reply --arp-mac-dst ! 52:54:0:56:44:32 -j DROP -p ARP --arp-ip-dst ! 10.33.8.131 -j DROP -p ARP --arp-op Request -j ACCEPT -p ARP --arp-op Reply -j ACCEPT -j DROP Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -s 52:54:0:56:44:32 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT -j DROP Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT -j DROP NB, we would have liked to include the prefix 'libvirt-' in all of our chain names, but unfortunately the kernel limits names to a very short maximum length. So only the first two custom chains can include that prefix. The others just include the TAP device name + protocol name. If I define a new filter 'no-spamming' and then add this to the 'clean-traffic' filter, I can illustrate how iptables usage works. # cat > /root/spamming.xml <<EOF <filter name='no-spamming' chain='root'> <uuid>d217f2d7-5a04-0e01-8b98-ec2743436b74</uuid> <rule action='drop' direction='out' priority='500'> <tcp dstportstart='25' dstportend='25'/> </rule> </filter> EOF # virsh nwfilter-define /root/spamming.xml # virsh nwfilter-edit clean-traffic ...add <filterref filter='no-spamming'/> All active guests immediately have their iptables/ebtables rules rebuilt. The network filter driver deals with iptables in a very similar way. First it separates out its rules from those the admin may have defined, by adding a couple of hooks into the INPUT/FORWARD chains Chain INPUT (policy ACCEPT 13M packets, 21G bytes) target prot opt in out source destination libvirt-host-in all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 5532K packets, 3010M bytes) target prot opt in out source destination libvirt-in all -- * * 0.0.0.0/0 0.0.0.0/0 libvirt-out all -- * * 0.0.0.0/0 0.0.0.0/0 libvirt-in-post all -- * * 0.0.0.0/0 0.0.0.0/0 These custom chains, then do matching based on the TAP device name, so they won't open holes in the admin defined matches for the LAN/WAN (if any). Chain libvirt-host-in (1 references) target prot opt in out source destination HI-vnet0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-in vnet0 Chain libvirt-in (1 references) target prot opt in out source destination FI-vnet0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-in vnet0 Chain libvirt-in-post (1 references) target prot opt in out source destination ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 Chain libvirt-out (1 references) target prot opt in out source destination FO-vnet0 all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-out vnet0 Finally, we can see the interesting bit which is the actual implementation of my filter to block port 25 access: Chain FI-vnet0 (1 references) target prot opt in out source destination DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 Chain FO-vnet0 (1 references) target prot opt in out source destination DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:25 Chain HI-vnet0 (1 references) target prot opt in out source destination DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 One thing in looking at this that you may notice is that if there are many guests all using the same filters, we will be duplicating the iptables rules over & over for each guest. This is merely a limitation of the current rules engine implementation. At the libvirt object modelling level you can clearly see we've designed the model so that filter rules are define in one place, and indirectly referenced by guests. Thus it should be possible to change the impl in the future so that we can share the actual iptables/ebtables rules for each guest to create a more scalable system. The stuff in current libvirt is more or less the very first working impl we've had of this stuff, so there's not been much optimization work yet. Also notice that at the XML level we don't expose the fact that we are using iptables or ebtables at all. The rule definition is done in terms of network protocols. Thus if we ever find a need, we could plug in an alternative implementation that calls out to a different firewall implementation instead of ebtables/iptables (providing that impl was suitably expressive of course) Finally, in terms of problems we have in deployment. The biggest problem is that if the admin does 'service iptables restart' all our work gets blown away. We've experimented with using lokkit to record our custom rules in a persistent config file, but that caused different problem. Admins who were not using lokkit for their config found that all their own rules got blown away. So we threw away our lokkit code. Instead we document that if you run 'service iptables restart', you need to send SIGHUP to libvirt to make it recreate its rules. Finally a reminder, that the main documentation we have on this is online at http://libvirt.org/formatnwfilter.html Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

1 0

[libvirt-users] VirtualBox driver : creating storage for a new machine
by Christian Patsch 28 Jun '10

28 Jun '10

Hi, Another thing I'm strugglin with: When creating a new domain from scratch using the proposed XML format in the documentation, everything works fine - basically. A problem that I'd like to solve now is that I would expect to be able to create new volumes within libvirt. I started with a basic XML file in order to define a pool, but virsh told me that creating pools is not supported by the VirtualBox hypervisor. >From the code and different hints I learned that there is only one pool with a dummy UUID, named "default-pool". Next I tried to create a new volume from a XML file, but the only thing I'm getting are segmentation faults. Has anybody used this approach successfully ? Otherwise I assume that I have to create the VDI files manually using VirtualBox GUI/VBoxManage or vboxshell.py. Thanks in advance, Regards, Christian

2 1

[libvirt-users] VirtualBox headless
by Christian Patsch 28 Jun '10

28 Jun '10

Hello, I'm trying to use the VirtualBox/vbox driver together with libvirt 0.8.1 on a Ubuntu Lucid Machine, VirtualBox Release 3.1. The goal is to run the virtual machines headless and to connect using RDP. When starting a virtual domain using 'virsh start <domainname>' the GUI of VirtualBox will pop up and I see no option to prevent this. If X is not running, the virsh command will terminate with 'unknown failure'. I've found some hints on inclusion of the headless statement in the 'graphics' part of the XML definition file, but when I tree to adopt this, the editing of the file will crash. Has anyone achieved to manage VBox machines with libvirt on a headless server ? Thanks in advance for some hints or experiences with this issue, Christian

2 2

[libvirt-users] can't access VM after Fedora 13 KVM install
by Joel Uckelman 28 Jun '10

28 Jun '10

Hi, I'm installing a Fedora 13 virtual host on a Fedora 13 system, like this: virt-install --ram 2048 --vcpus 4 --name test --os-type linux \ --os-variant fedora13 --disk /var/lib/libvirt/images/test.img,size=10 \ --cdrom /var/lib/libvirt/Fedora-13-x86_64-DVD.iso --vnc --noautoconsole I connect to the installer using virt-manager, and the install appears to complete successfully. Then, I reboot the virtual machine and reconnect with virt-manager. What I see is this: Starting SeaBios (version 0.5.1) gPXE (http://etherboot.org) - 00:04.0 C900 PCI2.10 PnP BBS PMM7FE0@10 C900 Booting from Hard Disk... If I connect to the VM's console using 'virsh console', there's no output at all. I don't see anything in /var/log/messages or /var/log/libvirt that looks like an error. So, I'm not sure what's going on here, as this is the first time I've done anything with virtualization. Has my VM hung, or is this what's supposed to happen? I was expecting that somewhere along the line that my VM would get an IP address via DHCP so I could SSH to it, but don't see anything indicating that has happend, or what the IP address is if it has. Is something broken here, or have I missed a crucial step? -- J.

1 1

[libvirt-users] network interface management in bridge firewall configuration
by Aleksander Trofimowicz 27 Jun '10

27 Jun '10

Hello, I'm just wondering why I can't manage my network interfaces through libvirt when the following kernel parameters are turned on: net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-arptables Is it a bug or by design? If the latter, could someone explain me premises of such decision? I'm aware of security implications of mixing conntrack and bridge bits, so we can skip that point. This behaviour is noticeable when using: libvirt-0.8.1-1.fc13.x86_64 netcf-libs-0.1.6-1.fc13.x86_64 -- thanks, aleksander trofimowicz

2 1