|
|
| Line 1: |
Line 1: |
| {{Anchor|Virtualization}} | | {{Anchor|Virtualization}} |
| | |
| == Virtualization == | | == Virtualization == |
| In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies. | | In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen- list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies. |
|
| |
|
| Contributing Writer: [[DaleBewley | Dale Bewley]] | | Contributing Writer: [[DaleBewley | Dale Bewley]] |
|
| |
|
| === Enterprise Management Tools List === | | === Enterprise Management Tools List === |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list] | | This section contains the discussion happening on the [https://www.redhat.com/ mailman/listinfo/et-mgmt-tools et-mgmt-tools list] |
| | |
| ==== Using VirtIO Network Driver for Windows KVM Guest ====
| |
| Working on Ubuntu, [[ArutyunyanRuben|Arutyunyan Ruben]] provisioned Windows
| |
| <code>KVM</code> guests using <code>virt-manger</code>, and wanted to use
| |
| <code>virtio</code>[2] drivers to speed up network access. After successfully using a
| |
| howto[3] to install this support, it was found to be missing after restarting the guest.
| |
| | |
| [[ColeRobinson|Cole Robinson]] answered[4] that <code>virt-manager</code> does
| |
| not support setting this option, but it can be accomplished manually by using <code>virsh dumpxml</code> and <code>virsh define</code>.
| |
| | |
| [1] http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00033.html
| |
| | |
| [2] http://wiki.libvirt.org/page/Virtio
| |
| | |
| [3] http://www.linux-kvm.com/content/tip-how-setup-windows-guest-paravirtual-network-drivers
| |
| | |
| [4] http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00034.html
| |
| | |
| ==== Mounting virt-p2v Disk Images ====
| |
| [[ParasPradhan|Paras Pradhan]] asked[1] how to mount images created by
| |
| <code>virt-p2v</code>. [[JoeyBoggs|Joey Boggs]] described[2] the process.
| |
| | |
| * Setup a loop device to the imagefile
| |
| : <code>losetup /dev/loopX domain.img</code>
| |
| | |
| * Read the partitions
| |
| : <code>kpartx -av /dev/loopX</code>
| |
| | |
| * Mount each partition as required
| |
| : <code>mount /dev/mapper/loopXpX /MOUNTPOINT</code>
| |
| | |
| After unmounting the partitions, the loopback devices should be removed with <code>kpartx -d</code> and <code>losetup -d</code>.[3]
| |
| | |
| [1] http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00026.html
| |
| | |
| [2] http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00029.html
| |
| | |
| [3] http://fedoraproject.org/wiki/Virtualization_Quick_Start#Accessing_data_on_guest_disk_images
| |
|
| |
|
| === Fedora Xen List === | | === Fedora Xen List === |
| This section contains the discussion happening on the [https://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list]. | | This section contains the discussion happening on the [https://www.redhat.com/ mailman/listinfo/fedora-xen fedora-xen list]. |
| | |
| ==== Status of dom0 Support in Upstream Kernel ====
| |
| [[PasiKärkkäinen|Pasi Kärkkäinen]] forwarded[1] a message[2] from [[Jeremy Fitzhardinge|Jeremy Fitzhardinge]], originally to the @xen-devel list, describing the state of dom0 support in the upstream <code>kernel</code>.
| |
| | |
| ".28 was a bit optimistic; (FWN#137[3]) .29 seems reasonable. The current dom0 kernel
| |
| patches can boot up to a fully functional dom0 usersmode, and you can
| |
| start xend to see that domain 0 is running. I *think* in theory you can
| |
| create a deviceless domain, but I haven't tried it. I'm currently
| |
| working on <code>blktap</code> support.
| |
| | |
| I really need to put together a proper status update. Now that dom0
| |
| usermode is working, its a much better base for other people start
| |
| contributing."
| |
| | |
| [1] http://www.redhat.com/archives/fedora-xen/2008-November/msg00011.html
| |
| | |
| [2] http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00205.html
| |
| | |
| [3] http://fedoraproject.org/wiki/FWN/Issue137#State_of_Xen_in_Upstream_Linux
| |
| | |
| Just two days later Jeremy posted[4] a large set of patches to @xen-devel with
| |
| the following explaination.
| |
| | |
| "A dom0 Xen domain is basically the same as a normal domU domain, but
| |
| it has extra privileges to directly access hardware. There are two
| |
| issues to deal with:
| |
| * translating to and from the domain's pseudo-physical addresses and real machine addresses (for ioremap and setting up DMA)
| |
| * routing hardware interrupts into the domain
| |
| | |
| ioremap is relatively easy to deal with. ..."
| |
| | |
| "... Interrupts are a very different affair. The descriptions in each
| |
| patch describe how it all fits together in detail, but the overview
| |
| is:
| |
| | |
| # Xen owns the local APICs; the dom0 kernel controls the IO APICs
| |
| # Hardware interrupts are delivered on event channels like everything else
| |
| # To set this up, we intercept at pcibios_enable_irq:
| |
| :* given a dev+pin, we use ACPI to get a gsi
| |
| :* hook acpi_register_gsi to call xen_register_gsi, which
| |
| :* allocates an irq (generally not 1:1 with the gsi)
| |
| :* asks Xen for a vector and event channel for the irq
| |
| :* program the IO APIC to deliver the hardware interrupt to the allocated vector
| |
| | |
| The upshot is that the device driver gets an irq, and when the
| |
| hardware raises an interrupt, it gets delivered on that irq.
| |
| | |
| We maintain our own irq allocation space, since the hardware-bound
| |
| event channel irqs are intermixed with all the other normal Xen event
| |
| channel irqs (inter-domain, timers, IPIs, etc). For compatibility the
| |
| irqs 0-15 are reserved for legacy device interrupts, but the rest of
| |
| the range is dynamically allocated.
| |
| | |
| Initialization also requires care. The dom0 kernel parses the ACPI
| |
| tables as usual, in order to discover the local and IO APICs, and all
| |
| the rest of the ACPI-provided data the kernel requires. However,
| |
| because the kernel doesn't own the local APICs and can't directly map
| |
| the IO APICs, we must be sure to avoid actually touching the hardware
| |
| when running under Xen.
| |
| | |
| TODO: work out how to fit MSI[5] into all this.
| |
| | |
| '''So, in summary, this series contains:'''
| |
| * dom0 console support
| |
| * dom0 xenbus support
| |
| * CPU features and IO access for a privleged domain
| |
| * mtrrs
| |
| * making ioremap work on machine addresses
| |
| * swiotlb allocation hooks
| |
| * interrupts:
| |
| ** introduce PV io_apic operations
| |
| ** add Xen-specific IRQ allocator
| |
| ** switch to using all-Xen event delivery
| |
| ** add pirq Xen interrupt type
| |
| ** table parsing and setup
| |
| ** intercept driver interrupt registration
| |
| | |
| All this code will compile away to nothing when <code>CONFIG_XEN_DOM0</code> is not
| |
| enabled. If it is enabled, it will only have an effect if booted as a
| |
| dom0 kernel; normal native execution and domU execution should be
| |
| unaffected."
| |
| | |
| [4] http://lists.xensource.com/archives/html/xen-devel/2008-11/msg00268.html
| |
| | |
| [5] http://lwn.net/Articles/44139/
| |
|
| |
|
| === Libvirt List === | | === Libvirt List === |
| This section contains the discussion happening on the [http://www.redhat.com/mailman/listinfo/libvir-list libvir-list]. | | This section contains the discussion happening on the [https://www.redhat.com/ mailman/listinfo/libvir-list libvir-list]. |
| | |
| ==== OpenVZ Bridge Support Committed ====
| |
| [[DanielBerrange|Daniel P. Berrange]] updated[1] a previous patch[2] designed
| |
| to "enable bridge support in the <code>OpenVZ</code> driver. As well as the fixes
| |
| suggested last time, it includes an initial bit of HTML doc for the
| |
| <code>OpenVZ</code> driver, covering example XML, and the bridge configuration
| |
| requirements."
| |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2008-November/msg00117.html
| |
| | |
| [2] http://www.redhat.com/archives/libvir-list/2008-October/msg00326.html
| |
| | |
| ==== Qemu/KVM Live Migration Implemented ====
| |
| [[ChrisLalancette|Chris Lalancette]] posted[1] the patch to implement Qemu/KVM live migration. After a little upstream cleanup[2], the patch was committed.
| |
| | |
| "Now that upstream Qemu has settled on an interface that is friendly to libvirt (i.e.
| |
| one that doesn't block the monitor on -incoming), we can implement it here.
| |
| Note that the bulk of this patch was written by Rich Jones quite a while ago.
| |
| My hand in it has mostly been to forward port it to current libvirt CVS, tweak
| |
| it for the new Qemu style, and test it out with a recent KVM (kvm-78, in
| |
| particular)."
| |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2008-November/msg00087.html
| |
| | |
| [2] http://www.redhat.com/archives/libvir-list/2008-November/msg00092.html
| |
| | |
| ==== Fix Logical Volume Scanning of Encrypted Volumes ====
| |
| [[ColeRobinson|Cole Robinson]] fixed[1] a bug[2] that prevented logical volume
| |
| scanning of an encrypted volume in a storage pool[3].
| |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2008-November/msg00138.html
| |
| | |
| [2] http://bugzilla.redhat.com/show_bug.cgi?id=470693
| |
| | |
| [3] http://www.libvirt.org/archstorage.html
| |
| | |
| ==== Greater Details from Domain Events ====
| |
| [[DanielBerrange|Daniel P. Berrange]] posted[1] an RFC on adding greater
| |
| detail to domain events. "...I'd like to have more information about STOPPED & STARTED events in general.
| |
| | |
| eg, there are a number of reasons why an domain may have started:
| |
| | |
| * explicitly booted on the host
| |
| * restored from a saved image
| |
| * incoming migration operation
| |
| | |
| and there are a number of reasons why a domain might have stopped:
| |
| | |
| * forcably destroyed by host admin
| |
| * shutdown by host admin
| |
| * shutdown by guest admin
| |
| * host emulator process crashed
| |
| * killed by mgmt after host emulation hung
| |
| * migrated to another host
| |
| * saved to a memory image
| |
| | |
| We have explicit events for the SAVED/RESTORED reasons, but what should
| |
| we do about the other reasons ?"
| |
| | |
| One option "is to provide a generic '<code>char * reason</code>' with each
| |
| event with provides scope on the cause of the lifecycle operation.
| |
| So you'd get"
| |
| | |
| <pre>
| |
| VIR_DOMAIN_STOPPED ("crashed", "shutdown", "destroyed",
| |
| "quit", "hung", "migrated", "saved")
| |
| VIR_DOMAIN_STARTED ("booted", "migrated", "restored")
| |
| </pre>
| |
| | |
| [[BenGuthro|Ben Guthro]] suggested[2] an alternative option of introducing "an event 'sub-type' enum to be passed alongside of the event-type, passed as a second integer", arguing this would be more consistent with the API and would reduce the size of the wire protocol.
| |
| | |
| | |
| [1] http://www.redhat.com/archives/libvir-list/2008-November/msg00164.html
| |
| | |
| [2] http://www.redhat.com/archives/libvir-list/2008-November/msg00171.html
| |
| | |
| Daniel agreed, and supplied[3] a patch which
| |
| "expands the callback for
| |
| domain events so that it also gets a event type specific 'detail' field.
| |
| This is also kept as an int, and we define enumerations for the possible
| |
| values associated with each type. If a event type has no detail, 0 is
| |
| passed.
| |
| | |
| The RESTORED and SAVED event types disappear in this patch and just become
| |
| another piece of 'detail' to the STOPPED and STARTED events. I have also
| |
| renamed ADDED & REMOVED to DEFINED and UNDEFINED to match terminology we
| |
| have elsewhere & because the names were confusing me."
| |
| | |
|
| |
|
| [3] http://www.redhat.com/archives/libvir-list/2008-November/msg00197.html | | === oVirt Devel List === |
| | This section contains the discussion happening on the [https://www.redhat.com/ mailman/listinfo/ovirt-devel ovirt-devel list]. |
