Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
Package: qemu-kvm Version: 0.12.3+dfsg-4 Severity: normal This is weird. I found it necessary to reinstall Debian/Squeeze. This shouldn't have affected my Windows XP/Pro VM since it was in my home directory. However, after reinstalling, Pinnacle Studio 9.4.3 doesn't build DVDs anymore. The program doesn't fail. It completes normally but the VIDEO_TS directory doesn't have all the files it should for a complete DVD. Windows Explorer shows the intermediate files correctly but consistently crashes when in that directory. I note that the .m2v files play correctly, as do the (partial) .vob files in the VIDEO_TS folder. Windows Explorer also runs very slowly when I'm looking at those directories. This suggested that a file system corruption may be the problem, but Windows chkdsk doesn't report any problems (NTFS file system in a .qcow file). I get the same behaviour whether I'm creating DVD5 or DVD9 files, and whether I clear out all the old files (maximize free space in my .qcow file) or create several DVDs in a row (using up the free space). I've tried: checking the Windows (virtual) disk drive, using different startup parameters, reinstalling Studio 9, etc.. So far nothing has worked. I did nothing to the Windows VM between the time Studio 9 was working (pre-reinstall of qemu-kvm) and when it stopped (post-reinstall qemu-kvm). My Windows install seems to be working OK except for the problems noted above. Any ideas? -- Package-specific info: /proc/cpuinfo: processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 4 model name: AMD Phenom(tm) II X4 940 Processor stepping: 2 cpu MHz: 3000.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 6026.93 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 1 vendor_id: AuthenticAMD cpu family: 16 model: 4 model name: AMD Phenom(tm) II X4 940 Processor stepping: 2 cpu MHz: 800.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 1 cpu cores: 4 apicid: 1 initial apicid: 1 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 6027.48 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 2 vendor_id: AuthenticAMD cpu family: 16 model: 4 model name: AMD Phenom(tm) II X4 940 Processor stepping: 2 cpu MHz: 800.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 2 cpu cores: 4 apicid: 2 initial apicid: 2 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 6027.47 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor: 3 vendor_id: AuthenticAMD cpu family: 16 model: 4 model name: AMD Phenom(tm) II X4 940 Processor stepping: 2 cpu MHz: 800.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 3 cpu cores: 4 apicid: 3 initial apicid: 3 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a mis
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
tags 578396 + moreinfo thanks 19.04.2010 19:20, Gary Dale wrote: Package: qemu-kvm Version: 0.12.3+dfsg-4 Severity: normal This is weird. I found it necessary to reinstall Debian/Squeeze. This shouldn't have affected my Windows XP/Pro VM since it was in my home directory. However, after reinstalling, Pinnacle Studio 9.4.3 doesn't build DVDs anymore. The program doesn't fail. It completes normally but the VIDEO_TS directory doesn't have all the files it should for a complete DVD. Windows Explorer shows the intermediate files correctly but consistently crashes when in that directory. I note that the .m2v files play correctly, as do the (partial) .vob files in the VIDEO_TS folder. Windows Explorer also runs very slowly when I'm looking at those directories. This suggested that a file system corruption may be the problem, but Windows chkdsk doesn't report any problems (NTFS file system in a .qcow file). Ok. Can you please re-create the .qcow file and see if that helps? Like this: kvm-img convert -O qcow2 windows.qcow windows2.qcow and see (after chkdsk run and re-creating the directory in question) if that fixes your problem? Also, verify that you have enough free space on the filesystem where your qcow file is. Another useful test is to check if raw format works. Do the same kvm-img convert but now with -O raw (it's the default btw). There were a few bugs in qcow2 format handler fixed during evolution of qemu/kvm, and some of these bugs lead to some corruption which can't be easily repaired even after the bugs are fixed. Overall, it is usually better (and faster too) to use raw image instead of qcow2. So far, the bug information is too vague to be of any use. It might be just due to some bug in the Pinacle Studio after all, or somewhere in windows XP - and upgrading of kvm just triggered that bug... I'm not saying it's definitely the case, but am trying to show that the number of possibilities is quite high. And the most likely cause is the bugs in qcow handler, which probably aren't part of qemu-kvm anymore. Also, you can try older kvm packages to see if your prob is still here. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
On 22/04/10 06:41 AM, Michael Tokarev wrote: tags 578396 + moreinfo thanks 19.04.2010 19:20, Gary Dale wrote: Package: qemu-kvm Version: 0.12.3+dfsg-4 Severity: normal This is weird. I found it necessary to reinstall Debian/Squeeze. This shouldn't have affected my Windows XP/Pro VM since it was in my home directory. However, after reinstalling, Pinnacle Studio 9.4.3 doesn't build DVDs anymore. The program doesn't fail. It completes normally but the VIDEO_TS directory doesn't have all the files it should for a complete DVD. Windows Explorer shows the intermediate files correctly but consistently crashes when in that directory. I note that the .m2v files play correctly, as do the (partial) .vob files in the VIDEO_TS folder. Windows Explorer also runs very slowly when I'm looking at those directories. This suggested that a file system corruption may be the problem, but Windows chkdsk doesn't report any problems (NTFS file system in a .qcow file). Ok. Can you please re-create the .qcow file and see if that helps? Like this: kvm-img convert -O qcow2 windows.qcow windows2.qcow and see (after chkdsk run and re-creating the directory in question) if that fixes your problem? Also, verify that you have enough free space on the filesystem where your qcow file is. Another useful test is to check if raw format works. Do the same kvm-img convert but now with -O raw (it's the default btw). There were a few bugs in qcow2 format handler fixed during evolution of qemu/kvm, and some of these bugs lead to some corruption which can't be easily repaired even after the bugs are fixed. Overall, it is usually better (and faster too) to use raw image instead of qcow2. So far, the bug information is too vague to be of any use. It might be just due to some bug in the Pinacle Studio after all, or somewhere in windows XP - and upgrading of kvm just triggered that bug... I'm not saying it's definitely the case, but am trying to show that the number of possibilities is quite high. And the most likely cause is the bugs in qcow handler, which probably aren't part of qemu-kvm anymore. Also, you can try older kvm packages to see if your prob is still here. Thanks! /mjt I've tried converting my original .qcow file to a new .qcow file and also to a raw file (which took a long time but seems faster than qcow, but is also larger - it seems to occupy the full space I initially created the virtual partition with). Unfortunately the problem still remains. The Pinnacle Studio program had been running but I don't know if there was a qemu-kvm update as part of my Squeeze re-install. How do I revert to an earlier package to test it? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
25.04.2010 17:17, Gary Dale wrote: [] I've tried converting my original .qcow file to a new .qcow file and also to a raw file (which took a long time but seems faster than qcow, but is also larger - it seems to occupy the full space I initially created the virtual partition with). Unfortunately the problem still remains. No, the raw image will actually use almost as much space as the qcow[2] one. Use `du' command to verify that. If you're curious, the key word "sparse file" is for you to find. The Pinnacle Studio program had been running but I don't know if there was a qemu-kvm update as part of my Squeeze re-install. How do I revert to an earlier package to test it? What exactly do you want to test? Is the issue you were experiencing (Pinnacle Studio not writing dvd images) still exist after you converted your disk image(s)? Or do you want to reproduce the problem you had(?) by installing earlier version? As of reproducibility(sp), it's not really worth to try to reproduce it - as I already mentioned before, there are lots of possible causes, and the bugs in qcow image handlers I mentioned aren't easy to trigger either, and they're fixed too. So if the issue is fixed, let's close the bug and move on. If not, and the program still does not work, please provide some more details about that. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
On 25/04/10 01:34 PM, Michael Tokarev wrote: 25.04.2010 17:17, Gary Dale wrote: [] I've tried converting my original .qcow file to a new .qcow file and also to a raw file (which took a long time but seems faster than qcow, but is also larger - it seems to occupy the full space I initially created the virtual partition with). Unfortunately the problem still remains. No, the raw image will actually use almost as much space as the qcow[2] one. Use `du' command to verify that. If you're curious, the key word "sparse file" is for you to find. Interestingly, neither format releases freed space. They just grow to the total allocated amount. DU does show they occupy the same amount of disk space, while dolphin shows the .qcow file at 46.4G and the raw file as the 50G I allocated for it when I initially create the virtual drive. The Pinnacle Studio program had been running but I don't know if there was a qemu-kvm update as part of my Squeeze re-install. How do I revert to an earlier package to test it? What exactly do you want to test? Is the issue you were experiencing (Pinnacle Studio not writing dvd images) still exist after you converted your disk image(s)? Or do you want to reproduce the problem you had(?) by installing earlier version? As of reproducibility(sp), it's not really worth to try to reproduce it - as I already mentioned before, there are lots of possible causes, and the bugs in qcow image handlers I mentioned aren't easy to trigger either, and they're fixed too. So if the issue is fixed, let's close the bug and move on. If not, and the program still does not work, please provide some more details about that. Thanks! /mjt The problem is NOT fixed. Prior to my re-installing Squeeze, Pinnacle Studio running in qemu-kvm was able to produce the proper video_ts directory. After the reinstall it reports that it has completed successfully but the files in the video_ts directory are not correct. The total video length is reported as correct by vlc, but the last VTS_01_x.VOB file is usually the wrong one, is too small and is corrupted after a certain point. For example, a typical DVD5 video with a simple menu structure would have VTS_01_0.VOB through VTS_01.5.VOB files, with the 0 file being the menu, the 1 though 4 files being the main content files (about 1G each in size) and the 5 file containing the remain 200M - 300M of video. Instead what I am getting is usually 0 and 1 files, perhaps a normal 2 and the next file (3) being only a couple of hundred megs but showing the length of the remainder of the movie. In my last test, for example, the 1 and 2 files where about 30 minutes each while the 3 file claimed to be about 90 minutes but only the first part would actually play. It's like Windows starts discarding writes to the 3 file so it never grows to the size where Studio would start another .VOB. Studio then terminates thinking it has produced a valid DVD directory (on my hard drive, not on optical media - burning is a separate step), not realizing that half of its work has never made it to disk. As I said, it sounds like file system corruption but chkdsk doesn't report any errors and two passes through the kvm convert should have fixed any problems. Moreover, my last test with the raw file was using an external usb hard drive while my previous runs were on my RAID5 array. BTW: my virtual drive is NTFS format so there should be no problems with large files. I never had this problem before the reinstall of Squeeze but get it consistently since the reinstall. The version of Pinnacle Studio I run is no longer supported so there were no updates to it. I don't recall any Windows XP updates either. I hate to have to go back and reinstall Windows XP - it's such a painful and long process that may or may not cure the issue if it is a bug in qemu-kvm. Do you have any other ideas before I resort to a complete fresh start? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
Further to below, I figured I'd try a re-install using virt-manager - something I couldn''t get working earlier. I noticed when I installed virt-manager, it installed a whole raft of software related to the qemu (not qemu-kvm) package. It also seems to be recognizing qemu-kvm, but I can't get Windows XP to install. Basically, I can connect to qemu (it won't connect to, or even recognize, qemu-kvm - the problem I was having earlier), create a new virtual machine (I have to pre-create the virtual disk file or it will try to create it on my system partition instead of in my home directory), tell it that it's a Windows XP partition then begin the install. Unfortunately, after copying files to the virtual disk, the XP install tries to reboot but can't find a bootable disk. I don't know if you can help out on that issue. But the various extra bits that virt-manager installed made me wonder if there is something in the qemu install (that is not in the qemu-kvm install) that could cause the issue I am having? I recall that when I was initially setting up my virtual machine I did have qemu installed, along with virt-manager, before I eventually got to qemu-kvm and a manual set up. Just a thought. Any ideas? On 25/04/10 01:34 PM, Michael Tokarev wrote: 25.04.2010 17:17, Gary Dale wrote: [] I've tried converting my original .qcow file to a new .qcow file and also to a raw file (which took a long time but seems faster than qcow, but is also larger - it seems to occupy the full space I initially created the virtual partition with). Unfortunately the problem still remains. No, the raw image will actually use almost as much space as the qcow[2] one. Use `du' command to verify that. If you're curious, the key word "sparse file" is for you to find. Interestingly, neither format releases freed space. They just grow to the total allocated amount. DU does show they occupy the same amount of disk space, while dolphin shows the .qcow file at 46.4G and the raw file as the 50G I allocated for it when I initially create the virtual drive. The Pinnacle Studio program had been running but I don't know if there was a qemu-kvm update as part of my Squeeze re-install. How do I revert to an earlier package to test it? What exactly do you want to test? Is the issue you were experiencing (Pinnacle Studio not writing dvd images) still exist after you converted your disk image(s)? Or do you want to reproduce the problem you had(?) by installing earlier version? As of reproducibility(sp), it's not really worth to try to reproduce it - as I already mentioned before, there are lots of possible causes, and the bugs in qcow image handlers I mentioned aren't easy to trigger either, and they're fixed too. So if the issue is fixed, let's close the bug and move on. If not, and the program still does not work, please provide some more details about that. Thanks! /mjt The problem is NOT fixed. Prior to my re-installing Squeeze, Pinnacle Studio running in qemu-kvm was able to produce the proper video_ts directory. After the reinstall it reports that it has completed successfully but the files in the video_ts directory are not correct. The total video length is reported as correct by vlc, but the last VTS_01_x.VOB file is usually the wrong one, is too small and is corrupted after a certain point. For example, a typical DVD5 video with a simple menu structure would have VTS_01_0.VOB through VTS_01.5.VOB files, with the 0 file being the menu, the 1 though 4 files being the main content files (about 1G each in size) and the 5 file containing the remain 200M - 300M of video. Instead what I am getting is usually 0 and 1 files, perhaps a normal 2 and the next file (3) being only a couple of hundred megs but showing the length of the remainder of the movie. In my last test, for example, the 1 and 2 files where about 30 minutes each while the 3 file claimed to be about 90 minutes but only the first part would actually play. It's like Windows starts discarding writes to the 3 file so it never grows to the size where Studio would start another .VOB. Studio then terminates thinking it has produced a valid DVD directory (on my hard drive, not on optical media - burning is a separate step), not realizing that half of its work has never made it to disk. As I said, it sounds like file system corruption but chkdsk doesn't report any errors and two passes through the kvm convert should have fixed any problems. Moreover, my last test with the raw file was using an external usb hard drive while my previous runs were on my RAID5 array. BTW: my virtual drive is NTFS format so there should be no problems with large files. I never had this problem before the reinstall of Squeeze but get it consistently since the reinstall. The version of Pinnacle Studio I run is no longer supported so there were no updates to it. I don't recall any Windows XP updates either. I hate to have to go back and
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
27.04.2010 07:54, Gary Dale wrote: Further to below, I figured I'd try a re-install using virt-manager - something I couldn''t get working earlier. I noticed when I installed virt-manager, it installed a whole raft of software related to the qemu (not qemu-kvm) package. It also seems to be recognizing qemu-kvm, but I can't get Windows XP to install. I'm not sure I understand what you wrote. In any way, it is something not related to the original bugreport, so if it is important for you file a new bug report. Basically, I can connect to qemu (it won't connect to, or even recognize, qemu-kvm - the problem I was having earlier), create a new virtual machine (I have to pre-create the virtual disk file or it will try to create it on my system partition instead of in my home directory), tell it that it's a Windows XP partition then begin the install. Unfortunately, after copying files to the virtual disk, the XP install tries to reboot but can't find a bootable disk. Here, perform the install of windowsXP without using virt-manager, directly with kvm running from command line. Later on you can "import" the guest disk image into virt-manager and it will work fine. It's a known issue and I don't yet know who's at blame -- virt-manager or kvm. I don't know if you can help out on that issue. But the various extra bits that virt-manager installed made me wonder if there is something in the qemu install (that is not in the qemu-kvm install) that could cause the issue I am having? As far as I know virt-manager is able to work with qemu, qemu-kvm, xen and a few other virt. technologies. Why it "decided" to install lots of qemu dependencies is beyong me, ask virt-manager folks about that. Again, it is not at all related to the problem at hand. Just a thought. Any ideas? Well, yes. We're getting too far from the initial problem. And the problem itself, as I already pointed out several times, isn't exactly clear either, it might be anything. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
On 27/04/10 03:42 AM, Michael Tokarev wrote: 27.04.2010 07:54, Gary Dale wrote: Further to below, I figured I'd try a re-install using virt-manager - something I couldn''t get working earlier. I noticed when I installed virt-manager, it installed a whole raft of software related to the qemu (not qemu-kvm) package. It also seems to be recognizing qemu-kvm, but I can't get Windows XP to install. I'm not sure I understand what you wrote. In any way, it is something not related to the original bugreport, so if it is important for you file a new bug report. The issue is that I didn't get a "connect to qemu-kvm" when I was trying to use it earlier. I'd removed qemu since it seemed to be unnecessary to running qemu-kvm. Right now, on the last "New VM" panel before it launches the VM to install the OS, it gives me (under advanced options) a choice between qemu and kvm (defaulting to kvm). So if I have both qemu and qemu-kvm installed, I appear to able to use virt-manger and it appears to recognize qemu-kvm. Just having qemu-kvm installed (or more precisely, qemu-kvm installed with qemu removed) didn't show anything to connect to. Basically, I can connect to qemu (it won't connect to, or even recognize, qemu-kvm - the problem I was having earlier), create a new virtual machine (I have to pre-create the virtual disk file or it will try to create it on my system partition instead of in my home directory), tell it that it's a Windows XP partition then begin the install. Unfortunately, after copying files to the virtual disk, the XP install tries to reboot but can't find a bootable disk. Here, perform the install of windowsXP without using virt-manager, directly with kvm running from command line. Later on you can "import" the guest disk image into virt-manager and it will work fine. It's a known issue and I don't yet know who's at blame -- virt-manager or kvm. OK. Thanks I don't know if you can help out on that issue. But the various extra bits that virt-manager installed made me wonder if there is something in the qemu install (that is not in the qemu-kvm install) that could cause the issue I am having? As far as I know virt-manager is able to work with qemu, qemu-kvm, xen and a few other virt. technologies. Why it "decided" to install lots of qemu dependencies is beyong me, ask virt-manager folks about that. Again, it is not at all related to the problem at hand. Possibly not, but as I mentioned, I probably had some of these files in my older Squeeze install but wouldn't have had them in my new install where qemu-kvm wasn't running Windows XP properly. Would qemu-kvm use them if they were installed before qemu-kvm was installed? Just a thought. Any ideas? Well, yes. We're getting too far from the initial problem. And the problem itself, as I already pointed out several times, isn't exactly clear either, it might be anything. /mjt I recognize that. I'm going to try the re-install of XP to see if that cures the problem. Unfortunately that won't tell us much about the cause of the original problem. If the fresh install works, that would indicate, to me anyway, that the problem was with qemu-kvm being missing something that the qemu install provides. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578396: qemu-kvm: After Squeeze reinstall, Studio 9.4.3 (Windows program) no longer works properly
Further to below: I did a complete reinstall of Windows XP in a fresh virtual machine and things are working again. Interestingly, after reinstalling Squeeze following a hard disk failure, virt-manager no longer connects to qemu so I'm back to running Windows XP from a kvm command. On 27/04/10 03:42 AM, Michael Tokarev wrote: 27.04.2010 07:54, Gary Dale wrote: Further to below, I figured I'd try a re-install using virt-manager - something I couldn''t get working earlier. I noticed when I installed virt-manager, it installed a whole raft of software related to the qemu (not qemu-kvm) package. It also seems to be recognizing qemu-kvm, but I can't get Windows XP to install. I'm not sure I understand what you wrote. In any way, it is something not related to the original bugreport, so if it is important for you file a new bug report. The issue is that I didn't get a "connect to qemu-kvm" when I was trying to use it earlier. I'd removed qemu since it seemed to be unnecessary to running qemu-kvm. Right now, on the last "New VM" panel before it launches the VM to install the OS, it gives me (under advanced options) a choice between qemu and kvm (defaulting to kvm). So if I have both qemu and qemu-kvm installed, I appear to able to use virt-manger and it appears to recognize qemu-kvm. Just having qemu-kvm installed (or more precisely, qemu-kvm installed with qemu removed) didn't show anything to connect to. Basically, I can connect to qemu (it won't connect to, or even recognize, qemu-kvm - the problem I was having earlier), create a new virtual machine (I have to pre-create the virtual disk file or it will try to create it on my system partition instead of in my home directory), tell it that it's a Windows XP partition then begin the install. Unfortunately, after copying files to the virtual disk, the XP install tries to reboot but can't find a bootable disk. Here, perform the install of windowsXP without using virt-manager, directly with kvm running from command line. Later on you can "import" the guest disk image into virt-manager and it will work fine. It's a known issue and I don't yet know who's at blame -- virt-manager or kvm. OK. Thanks I don't know if you can help out on that issue. But the various extra bits that virt-manager installed made me wonder if there is something in the qemu install (that is not in the qemu-kvm install) that could cause the issue I am having? As far as I know virt-manager is able to work with qemu, qemu-kvm, xen and a few other virt. technologies. Why it "decided" to install lots of qemu dependencies is beyong me, ask virt-manager folks about that. Again, it is not at all related to the problem at hand. Possibly not, but as I mentioned, I probably had some of these files in my older Squeeze install but wouldn't have had them in my new install where qemu-kvm wasn't running Windows XP properly. Would qemu-kvm use them if they were installed before qemu-kvm was installed? Just a thought. Any ideas? Well, yes. We're getting too far from the initial problem. And the problem itself, as I already pointed out several times, isn't exactly clear either, it might be anything. /mjt I recognize that. I'm going to try the re-install of XP to see if that cures the problem. Unfortunately that won't tell us much about the cause of the original problem. If the fresh install works, that would indicate, to me anyway, that the problem was with qemu-kvm being missing something that the qemu install provides. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
