Bug 212449
Summary: | virt-manager deletes my new VM | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Need Real Name <lsof> |
Component: | virt-manager | Assignee: | Daniel Berrangé <berrange> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | CC: | ncunning, xen-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | virt-manager 0.4.0-2 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-06-14 18:20:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2006-10-26 20:13:15 UTC
The 'restore' menu options isn't for starting inactive domains, its actually for restoring guests that have previously been suspended (aka hibernated/saved). So it is not expecting a raw disk image, but instead a VM suspend image. That said it ought to have detected that you supplied a bogus image & refused to proceed, rather than deleting it. It's amazing that it deleted it. Maybe the restore option could be more explicit too. I had powered off a VM and wanted to run it again. I presumed that was right. This is now fixed with validation that the image we are trying to get xen to restore is in fact a valid Xen Paravirt image. |