|
|
(230 intermediate revisions by 3 users not shown) |
Line 2: |
Line 2: |
|
| |
|
| {{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 of Fedora virtualization technologies on the |
| | @fedora-virt list. |
|
| |
|
| Contributing Writer: [[User:Dale | Dale Bewley]] | | Contributing Writer: [[User:Dale | Dale Bewley]] |
|
| |
| === Enterprise Management Tools List ===
| |
| This section contains the discussion happening on the
| |
| [http://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
| |
|
| |
| ==== New Release virt-manager 0.7.0 ====
| |
| [[ColeRobinson|Cole Robinson]] announce<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00058.html</ref>
| |
| a new {{package|virt-manager}}<ref>http://virt-manager.org/</ref> release, version 0.7.0.
| |
|
| |
| Virtual Machine Manager provides a graphical tool for administering virtual
| |
| machines for <code>KVM</code>, <code>Xen</code>, and <code>QEmu</code>. Start, stop, add or remove virtual devices,
| |
| connect to a graphical or serial console, and see resource usage statistics
| |
| for existing VMs on local or remote machines. Uses {{package|libvirt}} as the backend
| |
| management API.
| |
|
| |
| '''New features:'''
| |
| * Redesigned 'New Virtual Machine' wizard (Jeremy Perry, Tim Allen, Cole Robinson)
| |
| * Option to remove storage when deleting a virtual machine.
| |
| * File browser for libvirt storage pools and volumes, for use when attaching storage to a new or existing guest.
| |
| * Physical device assignment (PCI, USB) for existing virtual machines.
| |
| * Bug fixes and minor improvements.
| |
|
| |
| <references />
| |
|
| |
| ==== New Release virtinst 0.4.3 ====
| |
| [[ColeRobinson|Cole Robinson]] announce<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00057.html</ref>
| |
| a new {{package|python-virtinst}} release, version 0.400.3.
| |
|
| |
| <code>virtinst</code> is a module that helps build and install <code>libvirt</code> based virtual
| |
| machines. It currently supports <code>KVM</code>, <code>QEmu</code> and <code>Xen</code> virtual machines. Package
| |
| includes several command line utilities, including <code>virt-install</code> (build
| |
| and install new VMs) and <code>virt-clone</code> (clone an existing virtual machine).
| |
|
| |
| This is largely a bug fix release.
| |
|
| |
| <references />
| |
|
| |
| ==== ====
| |
|
| |
| <references />
| |
|
| |
|
| === Fedora Virtualization List === | | === Fedora Virtualization List === |
Line 52: |
Line 14: |
| [http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list]. | | [http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list]. |
|
| |
|
| ==== Serial Console Support in virt-manager ==== | | ==== Virt Status Report ==== |
| Jan ONDREJ tested<ref>http://www.redhat.com/archives/fedora-virt/2009-March/msg00028.html</ref> the new {{package|virt-manager}} 0.7.0 on Fedora 10, and had some suggestions.
| | [[JustinForbes|Justin Forbes]] |
| | | posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report. |
| {{Admon/note|TODO}}
| | Justin pointed out F13 bugs<ref>http://fedoraproject.org/wiki/Virtualization_bugs</ref> now include Important and Pony classifications in addition to Blocker and Target. |
| | |
| <pre>
| |
| Starting an domain starts my serial console owned by root and is not
| |
| accesssible from virt-manager (virt-viewer). After changing ownership it's
| |
| immediatelly available. Is it possible to change this in time of virtual
| |
| machine creation? (in libvirt or where?)
| |
| | |
| Another feature enhacement can be adding "Serial 0" tab automatically,
| |
| when there is no Console available for guest. Message "Console not
| |
| configured for guest" can be sometimes misinterpretated, because I can have
| |
| serial console for my guest. I prefer to use serial consoles, because they
| |
| do not need to install graphical environment on host. They have multiple
| |
| advantages, like access from another machine using serial or ipmi console,
| |
| viewing crash status, when host crashes, ...
| |
| | |
| And last possible enhancement: when pressing F10 key in guest's serial
| |
| console, is it possible to avoid opening of "File menu" and send this key to
| |
| serial 0, as it is done in VGA console?
| |
| </pre>
| |
| | |
| Cole
| |
| <ref>http://www.redhat.com/archives/fedora-virt/2009-March/msg00036.html</ref> | |
| <pre>
| |
| Yes, this is one of the drawbacks of not running virt-manager as root:
| |
| since the qemu:///system libvirt connection will launch your guests as
| |
| root, a regular user won't be able to access ptys.
| |
| | |
| I don't know of a proper solution to it all, other then running the app
| |
| as root or changing the the pty permissions as you did.
| |
| | |
| > Another feature enhacement can be adding "Serial 0" tab automatically,
| |
| > when there is no Console available for guest. Message "Console not
| |
| > configured for guest" can be sometimes misinterpretated, because I can have
| |
| > serial console for my guest.
| |
| | |
| I see what you mean. The wording could certainly be better, and It would
| |
| make sense to try to connect to the serial console if no graphics device
| |
| is attached. Thanks for the idea.
| |
| | |
| >
| |
| > And last possible enhancement: when pressing F10 key in guest's serial
| |
| > console, is it possible to avoid opening of "File menu" and send this key to
| |
| > serial 0, as it is done in VGA console?
| |
| >
| |
| | |
| We would probably need some sort of keygrab process like we do for VNC
| |
| to get this right. Not sure if that's even an option for the VTE widget
| |
| though.
| |
| </pre>
| |
|
| |
|
| <references /> | | <references /> |
|
| |
|
| === Fedora Xen List === | | ==== RHEL and Fedora Virtualization Feature Parity ==== |
| This section contains the discussion happening on the
| | Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4 |
| [http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
| | compared to Fedora 12. |
| | |
| ==== dom0 Kernel: Better, Still Not Ready ====
| |
| Itamar Reis Peixoto reported<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00046.html</ref>
| |
| success with [[MichaelYoung|Michael Young]]'s latest {{package|kernel}} build<ref>http://koji.fedoraproject.org/koji/taskinfo?taskID=1238587</ref> and wondered when it could be released.
| |
| | |
| Michael explained, "The current plan is to wait until basic <code>dom0</code> support makes it into the vanilla <code>kernel</code>, which should happen for 2.6.30, and then decide if <code>dom0</code> can be enabled and if the patches for full <code>dom0</code> support can safely be added without affecting ordinary operation."
| |
|
| |
|
| "At the moment there are still things that are broken such as <code>X</code> support in some cases, and there are also Fedora patches that have been omitted because they were tricky to merge, so it is too early to start adding <code>dom0</code> support to official Fedora kernels."
| | [[DanielBerrange|Daniel Berrange]] |
| | explained<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html</ref> |
| | "The KVM based virtualization in RHEL-5.4 is not nearly so far behind |
| | Fedora as you might think. The {{package|libvirt}} mgmt stack in RHEL-5.4 was |
| | rebased to be near parity with [[Releases/11|Fedora 11]], and KVM in RHEL-5.4 is |
| | also pretty close to that using what's best described as a hybrid of |
| | kvm-83 and kvm-84." |
|
| |
|
| <references /> | | <references /> |
|
| |
|
| ==== Missing Hypervisor Capabilities Restored ====
| |
| There was progress on a bug discovered<ref>http://fedoraproject.org/wiki/FWN/Issue166#dom0_Kernel_Inches_Closer</ref> last week. This missing file
| |
| <code>/sys/hypervisor/properties/capabilities</code> has been
| |
| restored<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00039.html</ref>,
| |
| however a bug<ref>https://bugzilla.redhat.com/show_bug.cgi?id=489799</ref> remained<ref>http://www.redhat.com/archives/fedora-xen/2009-March/msg00040.html</ref> in <code>libvirt</code> or <code>virt-install</code>.
| |
|
| |
|
| | ==== ==== |
| <references /> | | <references /> |
|
| |
|
| === Libvirt List === | | ==== ==== |
| This section contains the discussion happening on the
| |
| [http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
| |
| | |
| ==== Snapshot Support ====
| |
| In an attempt to make it easier to backup <code>KVM</code> windows guests,
| |
| Matt McCowan
| |
| created<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00177.html</ref>
| |
| a checkpoint <code>virsh</code> function. "Modelled on the <code>virDomainSave</code><ref>http://libvirt.org/html/libvirt-libvirt.html#virDomainSave</ref> function it takes
| |
| an optional script which it will execute (and pass the name of the
| |
| domain as an argument) while the domain is paused, then resume the
| |
| domain."
| |
| | |
| Daniel Veillard
| |
| commented<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00199.html</ref>
| |
| "I think this can help administrators in a controlled situation,
| |
| but I'm hoping a real snapshotting API will be possible at some point
| |
| where {{package|libvirt}} goes though the list of storage resources used by the
| |
| domain and properly make a snapshot using a storage API or return
| |
| an error if that's not possible."
| |
| | |
| Daniel P. Berrange
| |
| http://www.redhat.com/archives/libvir-list/2009-March/msg00205.html
| |
| <pre>
| |
| "In terms of API I think I'd like to see snapshotting available as part
| |
| of a more generic save/restore API. I tend to think of the current API
| |
| as providing 'unmanaged save/restore', in so much as libvirt / users
| |
| of libvirt have no way of knowing whether there is a saved image for
| |
| the guest available currently. As an example of why this is a problem,
| |
| consider the often requested ability to save/restore guests across
| |
| host reboot.
| |
| | |
| When libvirtd starts, it looks at the autostart flag for a guest, and
| |
| decides may thus automatically boot the guest at that time. libvirtd
| |
| has no way of knowing whether there was an existing saved image of the
| |
| guest available to restore, since it doesn't track saved images.
| |
| | |
| Thus I think the first step towards a general snapshot facility would
| |
| be to provide an API for 'managed save/restore' where we explicitly
| |
| track saved images.
| |
| | |
| | |
| - To save a guest:
| |
| | |
| enum {
| |
| VIR_DOMAIN_SAVE_LIVE, /* Don't shutdown guest after saving */
| |
| } virDomainSaveFlags;
| |
| | |
| virDomainCreateSaveImage(virDomainPtr dom,
| |
| const char *imagename,
| |
| unsigned int flags);
| |
| | |
| By default, imagename would be NULL, and flags would be zero. In this
| |
| case we'd simply be saving to
| |
| | |
| /var/lib/libvirt/saved/qemu/$VMNAME.img
| |
| | |
| Providing equivalence to current virDomainSave(dom, filename), but
| |
| with libvirt deciding the actual filename used.
| |
| | |
| Now to do snapshots in this scenario, you'd pass a 'imagename' for
| |
| the snapshot - give each snapshot you take some meaningful name as
| |
| you desire. And if VIR_DOMAIN_SAVE_LIVE is set then the guest will
| |
| be allowed to continue running after the snapshot is saved.
| |
|
| |
| Obviously this capability would require some way to take a snapshot
| |
| of the storage, as well as the memory image. We could allow a script
| |
| to do this, or implement it directly for a handful of storage types
| |
| we know can do this (eg, LVM, qcow2).
| |
| | |
| - Next, we'd need a way to list saved images
| |
|
| |
| virDomainListSaveImages(virDomainPtr dom,
| |
| const char **imagenames,
| |
| unsigned int *numimagenames);
| |
| | |
| This would just give back a list of all known imagenames for
| |
| the VM.
| |
| | |
| - Then a way to restore from an image
| |
| | |
| enum {
| |
| VIR_DOMAIN_RESTORE_DELETE
| |
| } virDomainRestoreFlags;
| |
| | |
| virDomainRestoreSaveImage(virDomainPtr dom,
| |
| const char *imagename,
| |
| unsigned int flags);
| |
| | |
| This would restore from the named image. If the VIR_DOMAIN_RESTORE_DELETE
| |
| flag was given, the named image would be deleted after restore (eg to
| |
| prevent accidental duplicated restore attempts)
| |
| | |
| - Perhaps also need a way to delete saved imaged
| |
| | |
| | |
| virDomainDeleteSaveImage(virDomainPtr dom,
| |
| const char *imagename);
| |
| | |
| If VIR_DOMAIN_SAVE_LIVE is set, the guest won't be shutdown after
| |
| saving its state.
| |
| | |
| | |
| - Perhaps also need a wa yto get more metaata about the save image | |
| | |
| struct virDomainSaveImageInfo {
| |
| int savedDate;
| |
| unsigned long long imageSize;
| |
| };
| |
| virDomainGetSaveImgeInfo(virDomainptr dom,
| |
| const char *imagename,
| |
| virDomainSaveImageInfoPtr info);
| |
| | |
| Then again, perhaps the virDomainListSaveImages should just return
| |
| a list of virDomainSaveImageInfoPtr instances directly, instead of
| |
| requiring this extra API call - it'd be faster for remote usage
| |
| in particular because it'd have less round-trips.
| |
| | |
| With this, you could configure libvirtd, so that when starting up, it
| |
| used virDomainListSaveImages to see if the guest was suspended before
| |
| the previous host shutdown, and if so, then restore from that saved
| |
| image automatically. Or make it skip autostart completely, if any save
| |
| images exist, and allow an admin defined initscript to do auto restore
| |
| from the save image.
| |
| "
| |
| </pre>
| |
| <references />
| |
| | |
| ==== Memory Ballooning Support for QEMU ====
| |
| Daniel P. Berrange
| |
| patched<ref>http://www.redhat.com/archives/libvir-list/2009-March/msg00200.html</ref>
| |
| the QEMU driver to fully suport full memory ballooning.
| |
| | |
| <references /> | | <references /> |